Repost: Icon Names Standard

Kenneth Wimer wimer at
Sun Sep 12 23:09:08 EEST 2004

* Frans Englich <frans.englich at> [Sep 12. 2004 15:35]:
> On Friday 10 September 2004 22:48, you wrote:
> > * Frans Englich <frans.englich at> [Sep 11. 2004 00:26]:
> > > On Friday 10 September 2004 07:22, ???????????????? ??????????????????
> > > wrote:
> > >
> > > Slightly related is "pseudo icons" which  I proposed on this list a
> > > couple of months ago. Food for thought:
> > >
> > >
> >
> > I think that this kind of thing undermines the whole point behind the
> > effort, actually. I think that one should start at the points that are
> > easily fixable and definable and then work forward. I admit that there
> > will always be a large difference in the needs between desktops but some
> > tihngs (many!) can be written down in stone now, so that we can move
> > forward.
> The idea of "pseudo icons" is simply the possibility for several icon names to 
> map to one actual icon; instead of duplicating/copying the actual files, a 
> mechanism(of some sort) do the actual mapping so the same icon is loaded.
> An icon names standard faces the problem of backwards compatability; 
> Applications (in the case of KDE, especially 3rd parties) would need to have 
> their code change to load the right icons when the standard is adopted in the 
> default icon theme. The "pseudo icon" concept would then be used as a 
> compatability layer where requests for old icon names didn't fail, but were 
> "redirected" to the renamed icons. Emigration would be easier, and the 
> standard faster adopted.

I disagree. Nobody will even know that they are breaking the standard if
they don't explicitly check and in this case nothing will be changed if
nobody knows that something is broken. Yes, emigration would be easier
because nobody would have to emigrate.

> I don't see how "pseudo icons" contradict an icon name standard; such one can 
> be written without pseudo icons, and without disturbing "pseudo icons". But, 
> the adoption of such a standard faces practical issues which such a concept 
> could help solving(and hence I threw out the idea).

This seems like more of a problem of implementation than specification.
I admit that a "feature rich" environment like KDE is going to need
something like this.

The most important thing that you should not forget is the fact that
if two or three different programs use the same visual metaphor for 
completely different actions the power of the metaphor is lost and
becomes useless or in some cases even confusing.

This is something that is very important as linux moves into the
business desktop market and although I don't want to sound hardcore I do
think that a little pressure to follow a well publiczied and widely
accepted specification is not a bad thing.

> How to implement "pseudo icons", would require investigating/following up 
> Alexander's reply.

Here is the most positive thing I can say about it:

Perhaps a second icon entry in the .desktop file could solve all of this
and introduce a new feature as well...until now when you change the icon
used for an app or whatever the path to the default icon is lost (so you
have to erase the starter or whatever and create a new one to get the
default back). Because 99% of the icons that do not comply with the spec
are not changeable in this manner anyway this would be a win-win kinda


SUSE Linux - a Novell Company - Nuernberg, Germany
Scheinbare Rechtschreibfehler beruhen auf einer individuellen

More information about the xdg mailing list