FS#11023 - kde packages and hicolor icon theme

Attached to Project: Arch Linux
Opened by Jan de Groot (JGC) - Monday, 28 July 2008, 08:09 GMT
Last edited by Pierre Schmitz (Pierre) - Sunday, 14 September 2008, 09:10 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Icons for KDE applications don't show up in my GNOME menu. This is caused by an outdated iconcache for the hicolor theme.
Please depend on hicolor-icon-theme for packages that install icons in /usr/share/icons/hicolor and add something like this to the postinstall/postupgrade of KDE applications:

if [ -x /usr/bin/gtk-update-icon-cache ]; then
gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
fi
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Sunday, 14 September 2008, 09:10 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in trunk
Comment by Pierre Schmitz (Pierre) - Monday, 28 July 2008, 08:45 GMT
Maybe we could find a cleaner solution here. I think it's quite wired if every app which installs icons have to update gnome's icon cache. I have found this interesting article at fedora: https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache

Even if I think Gnome should use inotify to check for changes . Anyway: we could add an update script to the hicolor-icons-package which does what described in this article: touching the several icons folders and running gtk-update-icon-cache. This could be simply called by all those install scripts.

xdg-icon-resource forceupdate --theme hicolor only updates the index, right?
Comment by Pierre Schmitz (Pierre) - Monday, 28 July 2008, 20:47 GMT
My cron will create a new filelist tomorrow. I'll have a look which packges would be affected. If there are many (I think so) one should think about a policy (best would be with namcap support).
Comment by Jan de Groot (JGC) - Monday, 28 July 2008, 21:02 GMT
There has been a policy for this, the GNOME package guidelines. Now KDE also installs icons in the same prefix as GNOME does, KDE should follow those guidelines also.
Comment by Pierre Schmitz (Pierre) - Tuesday, 29 July 2008, 12:26 GMT
Just to clarify: Is this valid for all packages that install something to /usr/share/icons or only the ones that change the content of r/share/icons/hicolor?

And is it enought to just call "xdg-icon-resource forceupdate --theme hicolor" in post_update/post_install and post_remove?
Comment by Jan de Groot (JGC) - Tuesday, 29 July 2008, 13:00 GMT
At this moment we only have a GTK icon cache for /usr/share/icons/hicolor. You can use xdg-icon-resource to update the cache, though that adds another dependency to xdg-utils. That command is a wrapper for the gtk-update-icon-cache command and will probably just bail out when it can't find gtk-update-icon-cache in the same way my proposed solution will skip updating the cache.
I'm thinking about adding an icon cache for /usr/share/icons/gnome also, but that doesn't affect KDE.
Comment by Pierre Schmitz (Pierre) - Tuesday, 29 July 2008, 13:42 GMT
The dependency to xdg-utils should not hurt; it's only a few KB. But it might be the cleaner solution, doesn't it? (btw: I just checked and it looks like > 200 packages affected by this)
Comment by Jan de Groot (JGC) - Tuesday, 29 July 2008, 13:58 GMT
Can you make a list of the ones in extra? There's already 93 packages implementing this in extra.
Comment by Pierre Schmitz (Pierre) - Thursday, 31 July 2008, 00:51 GMT
I attached a list of packages and its group. (and the used sql statement just for me to remember how I got this result ;-))
Comment by Jan de Groot (JGC) - Thursday, 31 July 2008, 06:36 GMT
Attached is a difflist between packages in your list and packages that have gtk-update-icon-cache calls. It seems there's also a few calling the command while they're not on your list.
Comment by Jan de Groot (JGC) - Thursday, 31 July 2008, 06:41 GMT
And here's another list. This one looks for "hicolor". It seems some icon theme packages are calling gtk-update-icon-cache on their own theme name, which made them appear in the other list incorrectly.
Comment by Pierre Schmitz (Pierre) - Thursday, 31 July 2008, 10:44 GMT
I have attached a more readable todolist :-) So there are only 44 packages left.

To sum things up:
* Every pacakge touching /usr/share/icons/hicolor should depend (directly or indirectly) on hicolor-icon-theme and xdg-utils.
* On post_update/post_install and post_remove "xdg-icon-resource forceupdate --theme hicolor 2> /dev/null" should be called

Todo:
* Document this in a short Policy in the public Wiki at http://wiki.archlinux.org/index.php/DeveloperWiki
* Update the packages mentioned in the todo list according to this policy
* inform arch-dev-public about this
* make a list of affected [community] packages and send a mail to aur-general
* write a simple namcap rule which looks for /usr/share/icons/hicolor and triggers a warning including a link to the policy

Are you fine with that?

Loading...