The problem of icon names

[Frans Englich]

On Wednesday 14 July 2004 23:58, Ingo Klöcker wrote:
> On Thursday 15 July 2004 01:28, Frans Englich wrote:
> > When we use icons in our applications, we look up one in the icon
> > theme matching our intent, and load it by its name. For example, the
> > restart button in the logout dialog uses Konqueror's reload icon
> > because it looks like what we wants.
> >
> > This causes a problem: it breaks the modularized design. When
> > Konqueror's reload button is decided to be updated, the new look does
> > perhaps not fit the intent in the logout dialog(or any other place it
> > is used). Not to think of when a whole icon theme is updated or
> > switched.
> >
> > I think the solution to this problem is to add an optional mapping
> > layer between the icons and the icon loading mechanism; the icon
> > theme can specify "the icon X goes under the name X, as well as the
> > pseudo icons named Z, Y and N." For example, the crystalsvg theme
> > could specify "the restart icon maps to Konqueror's reload icon."
>
> ... and set an appropriate symlink.
>
> > This has the following advantages:
> >
> > * It solves the modularity problem described above
> >
> > * It lowers the threshold of creating icon themes since one can cover
> > all icons usages without having actual icons for them.
> >
> >
> > In short, it significantly helps the problem of icon names being hard
> > coded, and gives additional flexibility. For example, if icon names
> > once becomes standardized, the icon names in the code can be changed,
> > and icon themes easily keep up without having to create icons.
> > However, "pseudo" icons would take a little longer to load(due to the
> > mapping overhead) and a similar result can be achieved by simply
> > copying the icons.
> >
> > Is it only me who sees this problem, or have I missed something
> > crucial?
>
> Which part of this can't be solved with symlinks?

Yes.. considering how fast it runs and relatively easy it is to implement, 
it's almost evil. It is truly transparent for the code, for bad and good.

If the mapping was done in code(instead of the build system), it would be 
aware of pseudo icons and optimizations could be done: loading of icons could 
be skipped, memory saved, transformations skipped, etc.(but I have no idea 
what I'm talking about; I have this vague memory of an icon server..). If an 
icon theme(or rather, special meta-data files) was used which only used a 
small amount of real icons, it could perhaps have a significant impact. 
Anyway, such vaporware dreams can be left to those who go and implement them.

I'll cook something up for the xdg icon theme spec(don't know when).


			Frans