Icon theme specification: Standardizing icon names
frans.englich at telia.com
Mon Oct 11 20:50:48 EEST 2004
On Monday 11 October 2004 02:05, Daniel Taylor wrote:
> This is great work! While I'm sure specifics will still have to be
> worked out, I'm glad to really see some major work being done to unify
> icon theming across the desktop. I hope this gets adopted by all the
> major players!
> As an icon theme author (of the original Lila themes, of which there
> are themes for GNOME/KDE/XFCE, Firefox, and various other contributed
> themes) I can really see the usefullness of this. Managing all those
> different themes is a royal pain, and it's really just mostly renaming
> files and/or creating slightly different configuration files (like
> We actually had the idea of creating a program to automatically convert
> themes, but never had a standard to write the themes for (that could
> then be used to generate all the different themes). There were also
> some problems with generating icons using emblem overlays (going from
> GNOME to KDE, for example), but svg-utils can do that now. Perhaps a
> program like that could still be useful (even if just to convert old
> themes to this new standard without any hassle)...
> Some questions:
> -How do you propose to handle mimetypes? GNOME and KDE differ wildly
> on this front (The GNOME makes more sense to me).
I haven't touched mimetypes at all because I think it can be discussed
separately, and is in another thread. Regarding the naming of mimetype icons,
it will probably(AFAIK) become a name derived from the mimetype name(no big
deal, some kind of pattern).
> -Should mimetypes be handled with emblems?
A similar question is if "new" actions(for example "create a new spreadsheet")
should be handled by emblems. This would be in one way simple for
implementors and theme writers, but on the other hand too restraining; there
can be cases where it's too primitive to simply have a "new" emblem smacked
over, or that the media type have a very loose relation to the mimetype. Of
course, nothing hinders the theme writer to manually copy&paste the different
components.. I don't think runtime overlays will be used for this purpose,
but the theme creators can be quite effective with templates(IOW, no use of
> -It would be a good idea to get quite a lot of application icons in
> the "default" set, especially apps that most desktop configurations
> will have. Web browser, chat program, mail program, multimedia apps,
> office apps, development apps, etc come to mind. Are these going to be
> included in the spec?
First of all, I don't think we want generic app icon names(as I proposed)
because applications are... application centric :), and that we won't be able
to convince projects to load the generic icons.
But, theming is possible anyway, because of the usual priority. For example,
firefox installs an icon into the hicolor theme, but if the theme installs a
firefox icon too, that one will be used.
Combined with a "pseudo icon" mechanism, the same result as generic app icon
names can be achieved; the relevant icon data file basically says
"IsAlso=konqueror;mozilla;galeon"(the icon is called firefox, for example),
and then all those icon requests result in the same icon. I think it also
scales, because new applications(popular and major ones) doesn't pop up
often, and it is quickly corrected. I doubt it will be used much, though.
Short answer: theming of application icons will be possible in either
> -Is it your stance that KDE (and other desktops) should adopt a
> GNOME-like emblem system (as in, would you make it the standard)? I
> believe this is a really useful feature.
GNOME has the emblem feature as part of the spatial concept, which in itself
must be optional and should not be part of the spec(not that I don't like it,
quite the contrary). But I nevertheless think the emblem group is useful, and
that a handful of arbitrary emblems are good too(so yes, GNOME's emblem
feature will be themable).
I think KDE should use emblems, not in the sense of the "spatial" feature, but
as method to apply folder attributes such as "read only" "locked" etc.
Because, it means: 1) Less icons to create; 2) A simpler spec, the
alternative is to create filesys folder icons for each attribute.
Also, KDE's "folder icons reflect content" should be implemented with
overlays, that the algorithm fetches suitable mimetype icons instead of
I don't think we should add filesys icons for various folder properties, but
instead say use "folder icon + emblem" and "folder + mimetype icon"(and KDE
But the important issue IMO is how to do a "pseudo mechanism", because
otherwise it will be a pain for theme creators, and the spec's success will
not be that obvious. The problem is it requires somekind of caching/lookup
mechanism, which no one has currently. For example, if an icon data file for
icon "foo" says "I correspond to the icon 'bar' and 'joe'", and the icon
loader code then looks for icon "joe", it can in no reasonable way figure out
to load icon "foo" without having an index.
Perhaps some of the mime issues could be solved with such an index. I've also
pondered on a cache mechanism which is one binary file; it contains metadata,
and then are all the images concatenated(similar to KDE ksycoca's format). It
would mean one read/seek, instead of hundreds of small files. It would also
make SVG rendering more viable; any image transformations would be cached in
that file. (yes, it's madness; I'm just thinking out loud)
BTW, I can't signup for KDE coding, I already got more than enough to do.
More information about the xdg