Caching icon theme information
frans.englich at telia.com
Wed Oct 20 22:37:21 EEST 2004
The danger of focusing on the negative aspects is people see nothing else.
On Wednesday 20 October 2004 17:52, Matthias Clasen wrote:
> On Wed, 2004-10-20 at 13:48, Frans Englich wrote:
> > Such a cache would allow theme creators to maintain only an SVG set, and
> > then have a tool which generates PNG version which then are embedded into
> > the cache file(assuming the image caching is implemented).
> > In the "Icon theme specification: Standardizing icon names" thread it
> > is evident that an "pseudo icon" mechanism is necessary, a method which
> > allows icon theme creators to say "this icon is also icon Foo, and icon
> > Bar" -- without copying/duplicating images or using symlinks. The
> > standardized names more or less relies on such a mechanism; many names
> > allows flexibility, while creators still have the possibility to cover
> > those names with a smaller set of actual images. Depending on how it's
> > implemented, it also allows the creation of high performing icon
> > themes(embedded devices etc).
> > My idea of specification is that the icon data file has an IsAlso field
> > which is a semi colon separated string with the icon names it covers. For
> > example, the icon data file for icon "navigator-reload" could have
> > "IsAlso=system-reboot;document-reload;" and lookups on system-reboot
> > would load the navigator-reload icon, for instance.
> > However, that IsAlso directive doesn't allow it to be done in a efficient
> > and quick way. Perhaps this can be done with the cache? Like this:
> > Add a '4 CARD32 REAL_ICON_OFFSET' to Icon, which is the offset to the
> > real Icon. If set to zero, the icon is not a pseudo icon.
> > Implications(AFAICT):
> > * The file size increases with 4*<number of icons>.
> > * IMAGE_LIST_OFFSET wouldn't make sense for pseudo icons then, and it
> > should be zeroed.
> > * It would complicate the cache generator.
> > * Converting to the standardized icon names once it's in the spec, will
> > more or less require support for the IsAlso directive, and hence the
> > cache(or doing it in some other way).
> The icon cache is strictly a cache of the information found in the
> file system. I don't think it should be a vehicle to implement
> extensions of the icon theme specification. If IsAlso can't be
> implemented in an reasonable way without the icon cache, it should
> be redesigned/rejected.
But it is in the nature of IsAlso to require a reverse mapping. The theme
creator wants a mapping like this(ascii art):
Foo(real icon) -+--> Joe(pseudo)
(not neccesarily, but it's the far the most practical for everyone)
While icon lookup code wants this mapping:
Bar -> Foo
Joe -> Foo
Boo -> Foo
Just because we add the possibility for the cache to contain pseudo icon
mappings, doesn't mean it becomes mandatory. It only is a highly attractive
way to implement it, implementations may skip or do it in some other way. I'm
* What is the negative side of adding the capability to the cache? In other
words, why /not/ add it to the cache?
* Do you have a suggestion to how to otherwise reach the result of IsAlso?
More information about the xdg