Icon theme specification: Standardizing icon names

[Daniel Taylor]

On Oct 11, 2004, at 15:23, Frans Englich wrote:
> On Monday 11 October 2004 19:02, Daniel Taylor wrote:
> I think it does. One of the most annoying things while creating Lila
>> was that there is no authoritative listing of icon names. We had to
>> scrounge the various themes for possible names, and this is a real
>> blocker for anyone wanting to get into theme creation.
>>
>> When we are talking about standardizing these icons, are we talking
>> about making them mandatory, or would they fall back to the "default"
>> theme if not found in the currently loaded one? If they aren't
>> mandatory, then I think it's fine. You start with the most obvious 
>> ones
>> and slowly fill in the blanks, until you have a full theme.
>
> A theme fallbacks to the theme it inherits(etcetera, until hicolor is 
> reached,
> which is the "base/super" theme). So GNOME look-a-like themes would 
> probably
> inherit from gnome's theme(and hence have it as a dependency), and 
> others on
> crystalsvg. The hardcore ones would go directly on hicolor.

Then I see no problem with having such a high number of standardized 
icons. I'd much rather see a single inbox icon, a single table left 
align icon, etc. than having each program specify its own; we end up 
with the same mess we have now if every app creates its own icons. 
Isn't the point of the standard partially to help keep this unneeded 
duplication from happening?

Why are a lot of people against standardizing so many icons? I don't 
quite understand the reasoning... :(

> It's a quite efficient way of bootstrapping icon themes. For example, 
> KDE
> could inherit gnome's theme to cover icons it doesn't have, in order to
> quickly ensure compatibility for non-KDE apps, and go back to hicolor 
> when
> suitable(GNOME could do the same).

I would hope that if this gets adopted there would be no "KDE" or 
"GNOME" themes, just standard icon themes that any application could 
use.

> Regarding the icon count; _very_ many icons can be covered by using a 
> "pseudo
> icon" mechanism, mapping many icon names to one icon.

What did you think of my idea from the other mail about handling 
"pseudo icons" through function or category based file naming schemes? 
What is the advantage of maintaining a separate index of icon or 
application names. It seems like a lot of overhead compared to falling 
back on the next closest categorical or functional icon (e.g. 
"apps/graphics-vector.svg" when "apps/graphics-vector-inkscape.svg" 
isn't found).
--
Daniel G. Taylor
http://programmer-art.org