Icon caching is unusable

[Matthias Clasen]

On Mon, 2005-10-03 at 17:13 +0200, Josselin Mouette wrote:
> Hi list,
> 
> Sorry if it's already been brought, but I can't find a clean way to use
> the caching mechanism described in the icon theme specification. Here is
> an excerpt from that specification:
> 
>         In order to handle this any implementation that does caching is
>         required to look at the mtime of the toplevel icon directories
>         when doing a cache lookup, unless it already did so less than 5
>         seconds ago. This means that any icon editor or theme
>         installation program need only to change the mtime of the the
>         toplevel directory where it changed the theme to make sure that
>         the new icons will eventually get used. 
> 
> This may sound good on the paper, but this way, icon caching is almost
> unusable. Most of the time, the installation program won't change the
> mtime of the toplevel directory. The icon theme specification has
> existed for some time now without any caching implementation, and tools
> are accustomed to just install icons in /usr/share/icons/$theme without
> question.

GTK+ has an icon theme cache for almost a year now.

> The result is that icons are simply shipped into tarballs, .rpm or .deb
> packages, or installed by automake. None of these tools changes the
> mtime of the toplevel icon directory. The probability that even one of
> these tools is changed to achieve that is close to zero. As such, it
> isn't possible to use icon caching. Installing a new icon won't make it
> appear automatically if you're using the cache.

If you look at Fedora, this is handled in the %post hook of all packages
that install icons. Installing an icon is a two-step process 

1) copy the icon to the right directory
2) touch the toplevel theme directory

This has always been the case, even before caching was implemented. 

Could this be nicer ? Sure. 
Does it make it impossible to use icon caching ? No. 

> The current way of dealing with this brokenness is to work around it
> using scripts that run gtk-update-icon-cache - at least that's what
> we've started to do for icons in Debian. However that's not how a cache
> is supposed to work.
> 
> A possible way to go would be to check not only for the toplevel
> directory's mtime, but also that of all directories referenced in
> index.theme. However I'm afraid it would be suboptimal.

See, the requirement to touch the toplevel directory was introduced
specifically to avoid having to run the entire hierarchy all the time...

> Other ideas?

If it bothers you so much, why don't you write a little utility which 
installs an icon, taking care of the touching. 


Matthias