Icon theme specification: Standardizing icon names

[Frans Englich]

On Wednesday 13 October 2004 14:42, Daniel Taylor wrote:
> 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,

(Is there multiple inbox icons? Where?)

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

I don't see it as duplicates, and those icons aren't application specific. 
What they do, by design, is to make actions specific on the substantive. For 
example, applications want icons to not say merely "add", but say "add table 
cell", or "add text field", etc. I don't comment on its validness, but that's 
what people do.

However, if you, as a theme creator, want to have one "add" or one "insert" 
action, /regardless/ of context(whether it's text, table, object, image 
etc.), then you simply use the "pseudo mechanism" and says icon 
"standard-insert" corresponds to "document-insertfile ;image-insert; 
table-cells-insert; table-insert" etc. etc., for any combinations you like.

And how that "pseudo mechanism" is implemented(for example an IsAlso= field in 
the icon data file), can be taken a closer look at when the index work is 
brought to discussion.

>
> 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.

Yes, that will be the result in either case. I think you need to check out the 
theme inheritance mechanism in the spec.

>
> > 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).

The index would be transparent to theme creators, it's only a technical 
implementation to make lookups fast enough. You can't do "pseudo icon" with a 
fallback mechanism(it only works for application icons as you propose), 
because it can't be guessed what icons the creator have decided should map to 
what. 

I don't think icon fallback for application icons as you propose is a good 
idea, because the application specific icons /will/ always exist(in hicolor). 
If you mean that when "graphics-vector-inkscape" isn't found in the current 
theme("your theme"), it should fallback to "graphics-vector", that means the 
icon the app provided will never be shown, and I think that's too far.

However, if you want to override a particular application icon, you simply 
create an icon with the same name, or with the "pseudo mechanism" say what 
applications it should be loaded for. In other words: Yes, overriding 
application icons requires hard coding, but individual app icons must go 
through, or require individual theming by the theme -- that's why I've 
withdrawn "generic app icons", also see Ryan's(RealNetworks) comment on it.


Cheers,

		Frans