Icon theme specification: Standardizing icon names

[Frans Englich]

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
> gtkrc).
>
> 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 
emblems/overlays).


>
> 	-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 
case(AFAICT).

>
> 	-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 
emblems(less icons).

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

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.


Cheers,

		Frans