To me this sounds a bit too complicated and "one theme too much
related". providing themes shouldn't be so hard. 
I think we should look at common storing first, and then how to
activate the theme...

i erased some unanswered parts of this post.

BP> the trouble begins with the ELEMENTARY THEME:
BP> 
BP> [*]i want to display a warning message (befor the installation
BP> process) that the user should remove the neo theme before
BP> installing any other elemetary themes (are there any apart from
BP> sixteen?) so that the user can press ctrl+c if he doesnt want to
BP> install it, because if the proper scripts are missing something
BP> might go wrong [that should not be that big of a problem for me,
BP> but just in case i'd like to have it done by someone else].

why would it be good to remove this particular theme? couldn't they
live side by side?


BP> the troubles continue with the SHR APPS edje data collections:
BP> 
BP> [*] i want to backup every .edj file in 
BP> /usr/share/libframeworkg-phonegui-efl before the neo theme's edj
BP> files are placed there so i dont overwrite the default files.. [my
BP> idea would be to append .back te every edj file in this
BP> directory... theoretically i know how to do it, but i want to be
BP> absolutely sure that my them package doesnt overwrite any default
BP> files so that the user can switch back to the default look if he
BP> removes the neo theme]

i think that either the libframeworkg-phonegui-efl should
support theming parameter or the themes should sit in
usr/share/libframeworkd-phonegui-efl/theme which would be a link to for
example usr/share/libframeworkd-phonegui-efl/neo. shr-settings could
handle this (as we have the same for splash already...)


BP> 
BP> the troubles go on with the ETK THEME
BP> 

etk already has themes dir so symlinking it or symlinking the
default.edj only would work... or?

BP> final problem:
BP> 
BP> [*] when the user removes the neo theme i want to revert all these
BP> steps mentioned above.

wouldn't be an issue then...


Petr
_______________________________________________
Shr-User mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-user

Reply via email to