RFC: GTK+ icon cache
Hi list,
there is an ongoing disagreement in the GNOME team about the handling of
icon caches, and we (or at least, I) would appreciate more input. Let me
try to sum it up.
1. The issue
Desktop environment and applications are using more and more icons, for
many reasons. They are put in /usr/share/icons/$theme/$size/$purpose/
directories. This way, an application looking for an icon will have to
look through the whole directory structure of /usr/share/icons/$theme
for the current theme and all themes it inherits from. This is very
slow.
2. The cure
A mmap()-able cache file format was proposed, and is generated by
gtk-update-icon-cache in /usr/share/icons/$theme/icon-theme.cache files.
It helps a lot to improve speed.
3. The side-effect (for an euphemism)
The current code in GTK+ follows the freedesktop.org specification: if
the mtime of /usr/share/icons/$theme/ is more recent than that of
icon-theme.cache, the cache is considered outdated, and the whole
directory structure is read instead. As a result, if an application
installs a new icon, of course the mtime of a directory two levels up
isn't changed. When started, the application doesn't find the icon. Some
applications only become ugly, some simply refuse to launch.
4. The current state of affairs
In sarge - and this is still the case in unstable - the icon cache is
generated for most themes, but not for "gnome" and "hicolor", which are
the default directories applications install icons in. That means some
themes in gnome-themes-extras (which don't inherit from gnome) benefit
from the icon cache, but other themes (especially the default) don't.
5. The proposed solution
The Redhat people, who implemented the cache specification, obviously
don't have problems with applications suddenly becoming unusable after
some change: they started to generate cache for all directories,
automatically adding post-installation snippets to the application
packages. As "this worked", and as the GTK+ developers - which happen to
be partly the same people - don't want to change the code, their
recommendation is to do the same for Debian. Applying this solution
means that, as soon as some packages start using the new debhelper
snippet, hundreds of other packages will more or less break when
installed after the cache generation.
In short, some people in the GNOME team want to apply this solution
nevertheless, while other people (including me) don't want of it.
Alternative proposed solutions are to keep things as they are in sarge,
or to change the code to check for the mtime's of all subdirectories
(which of course would be slower). I'm not searching for support here,
but for a decision. If a consensus about applying it arises, I'll apply
it - I even already started to write the debhelper script.
Regards,
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
Reply to: