[yast-devel] module icons
Hi, Are there any examples of how to put an icon for your module into the RPM package for a module? All the icons for the modules that ship with the distro seem to be in a separate RPM, but I want to package an icon with my custom module. Cheers, KEv. -- Kevin James Applied Technology Senior Strategist Novell Global Enablement ------------------------ Novell, Inc. http://www.novell.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Kevin James wrote:
Hi,
Are there any examples of how to put an icon for your module into the RPM package for a module? All the icons for the modules that ship with the distro seem to be in a separate RPM, but I want to package an icon with my custom module.
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 ... Anyway, there is a possibility how to package it, part of your .spec.in file: %dir @themedir@ %dir @themedir@/current %dir @themedir@/current/icons %dir @themedir@/current/icons/22x22/ %dir @themedir@/current/icons/22x22/apps/ %dir @themedir@/current/icons/32x32/ %dir @themedir@/current/icons/32x32/apps/ %dir @themedir@/current/icons/48x48/ %dir @themedir@/current/icons/48x48/apps/ @themedir@/current/icons/22x22/apps/${YOUR_ICON}.png @themedir@/current/icons/32x32/apps/${YOUR_ICON}.png @themedir@/current/icons/48x48/apps/${YOUR_ICON}.png ${YOUR_ICON} should be, of course, replaced with your icon name... Bye Lukas
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. 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/ 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. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
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
Lukas Ocilka wrote:
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?
Well, the pattern is there, the proposal would need to get the YaST paths there, still needs to be done.
That would need to have a designer creating all the icons for all themes.
No, nothing is worse than in the current case. It fixes sane dependencies (no need to update the theme package all the time). The designer provides icons for the themes he can provide icons to (normally at least one per icon). Is reposability of the iconloader to get the right one given name and size, and doing the right fallback if certain themes are not available. The logic of the fallback (ie: try to use the most similar theme) is encapsulated there. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (3)
-
Duncan Mac-Vicar Prett -
Kevin James -
Lukas Ocilka