Duncan Mac-Vicar Prett wrote:
Lukas Ocilka wrote:
It's not a good idea to put that icon to your RPM because user can have several icon-themes installed in /usr/share/YaST2/theme/ directory at once. The current theme in use is symlinked from the "current" directory ... and yes, we know it is confusing :) ;) we now it is not ideal ...
(back to the old discussion), it actually makes sense. Otherwise a theme has to know all icons for all modules.
Continuing with the old discussion ... What actually makes sense? To package your own icons? Of course it "makes sense" but *not* with the current implementation, we have to change the core functionality, define rules first: * order of paths to search for icons * default paths * packaging rules Would you like to create an easy to understand proposal how to change the current behavior with minimal effort for developers that use it?
If you look desktop environments for example, the theme provides icons:
oxygen-icon-theme: /usr/share/icons/oxygen/*
However, kde4-kopete also provide icons for that theme, for other themes too
/usr/share/kde4/apps/kopete/icons/crystalsvg/ /usr/share/kde4/apps/kopete/icons/hicolor /usr/share/icons/oxygen/
That would need to have a designer creating all the icons for all themes.
some are specific to the application (in apps/kopete/icons), and other that are not specific, like actions that can be used by programs that depend on kopete for example (who want to use those actions).
/usr/share/icons/oxygen/22x22/actions/webcamreceive.png
I find this model much more consistent. It is like a solved problem we reinvent in a bad way.
I hope HuHa will comment this :) Bye Lukas