Icon theme specification: Standardizing icon names

[Frans Englich]

On Monday 11 October 2004 22:03, Ryan Gammon wrote:
> Frans Englich wrote:
> >Hello everyone,
> >
> >Attached is a patch which standardizes 1048 icon names, compiled from the
> >~2050 icons which KDE and GNOME in all houses. While that sounds like a
> > lot, and bizarre for that matter too, the important question is where
> > this is heading, what we want to achieve, and why.
>
> Cool. I like icons like:
>
> document-new
> edit-copy
>
> ... etc.
>
> Some of them are a little less core:
>
> calendar-view-work-week
> pciexpress
> table-size-fit-width

Yes, as stated in the top post, many groups needs redesigning(and it is such a 
time killer..). I will work those groups over, and once we have names which 
are as sane as possible, everyone list every name which they can't easily 
figure out, and we add descriptions for them.

>
> Maybe we could separate these into categories? Maybe base, office,
> media, etc? 

Ok, a more rigorous namespace will be in the next draft.

> Apps could require a certain level of icon theme-ed-ness in 
> order to be fully themed.

I've thought about this, the spec could have various "levels {1,2,3}", and 
themes could then live up to the levels, and applications could depend on 
them as suitable. But I don't think it's a good idea, because it's 
unnecessary, adds complexity, and makes dependencies to detailed -- too much 
micromanagement. A 3rd party theme could inherit one of the major ones such 
as crystalsvg or gnome-icon-theme and in this away achieve full compliance, 
and override icons as to taste. The result is the same as having "levels", 
since not having icons available is not an option(and one have to hence 
inherit anyway).

>
> Will document (mime type) icons ever appear in this spec? Would
> RealAudio/RealVideo mime type icons eventually show up in a fdo spec?
> How does RealAudio/RealVideo and RealPlayer work with this proposal?

The mimetype icons issue is left out in this discussion(to take one thing at a 
time :). The mime-icons naming scheme for /icon themes/, will probably be 
derived from what the fd.o's mimetype database says, and since Real file 
types are in it, there will be names for those as for any other mimetypes. 
You perhaps wonders how that affects priority, and how you should 
name/install your own mimetype icons, but that's a separate discussion.

>
> >* There's a big difference between how GNOME and KDE handles folder
> >attributes. GNOME uses "emblems" as overlays, partly in its spatial
> > browsing concept. KDE has the "folder reflects content" feature and
> > indicators for read only folders, for example. KDE doesn't use overlays,
> > but use ordinary folder icons modified by hand. Should we agree on a
> > method for this? (I would say KDE should switch to overlays and the
> > emblem group to be extended) Or should we have emblems as well as folders
> > like KDE do?
> >It should also be asked if scaled mimetype icons(as overlays) should be
> > used instead of emblems, especially for KDE's "folder reflects content".
> > Otherwise it will be an endless adding of emblems.
>
> If emblems are standardized, will there be a fdo spec like the gnome hig
> for how to draw emblems? (perspective, palette, lighting, etc)?

No. That's a "semantical" aspect, and the theme mechanism distributes exactly 
those decisions. It would be possible to spec the design of hicolor though, 
although I can't see the point with it. It would also be a bureaucratic 
jungle.

>
> http://developer.gnome.org/projects/gup/hig/2.0/icons.html#icons-style
>
> >* In the patch there is standardized application icons for common ones,
> > which allows simple programs to easily be themed, without having to
> > bother with individual applications(but this can also be solved with
> > pseudo icons). Is this a good idea or would it only be ignored?
>
> I'm sure we'd have a strong preference for RealPlayer to show up with a
> Real icon, and not a generic media player icon -- it would be ignored by
> us.

Yes, generic app icon names is a bad idea. However, if an icon theme author 
decides to theme your application icon, by installing an icon with the same 
name as your icon into his/her theme, that would override your application 
icon(that's how it works).


Cheers,

		Frans