Caching icon theme information

[Frans Englich]

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"[1] 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):

		 +-> Bar(pseudo)
                /
Foo(real icon) -+--> Joe(pseudo)
                \
                 +-> Boo(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 
wondering:

* 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?


Cheers,

	Frans