Icon theme specification: Standardizing icon names

[Daniel Taylor]

On Oct 11, 2004, at 13:50, Frans Englich wrote:
> On Monday 11 October 2004 02:05, Daniel Taylor wrote:
>> *snip*
>> 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)

I just want to say I agree with naming based on the mimetype (that is, 
the entire mimetype). So "mimetypes/text-plain.svg" instead of GNOME's 
"mimetypes/gnome-mime-text-plain.svg" and KDE's "mimetypes/text.svg."

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

Alright, I can live with that.

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

Just thinking out loud, but as I recall e.g. GNOME will fall back to 
gnome-mime-text.svg when there is no gnome-mime-text-plain.svg. Would 
it be wise to implement something similar to applications? That is, to 
name the app icons in a style similar to "function-name," like 
"network-web-browser" or "network-ftp-client?" App authors could then 
set their apps names like "network-web-browser-epiphany" or 
"network-web-browser-mozilla-firefox" etc... If their specific icons 
aren't found it would fall back to the next cosest generic icon. 
Wouldn't this eliminate a need for the "pseudo icon" idea?

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

Doesn't this mean you do want emblems in the spec (even if only a 
limited set)? I don't quite understand how they are part of the spatial 
concept? A lot of the icons in various desktops could easily be 
generated using emblems.

> Also, KDE's "folder icons reflect content" should be implemented with
> overlays, that the algorithm fetches suitable mimetype icons instead of
> emblems(less icons).

By overlay I assume you mean using another icon as an emblem (i.e. an 
emblem, just not the ones that are listed, instead mimetype icons as 
you list below).

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

This makes a lot of sense to me.

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

What do you think of the fallback method I wrote about above? It is 
reasonable, or just a hack that we would wind up regretting horribly? 
It would eliminate the need for 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.

I don't have that much time on my hands, either. I also mostly work 
with GNOME and GTK, so I wouldn't even know where to start!
--
Daniel G. Taylor
http://programmer-art.org