Icon theme specification: Standardizing icon names
dantaylor at web.de
Mon Oct 11 21:55:52 EEST 2004
On Oct 11, 2004, at 13:50, Frans Englich wrote:
> On Monday 11 October 2004 02:05, Daniel Taylor wrote:
>> 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
> 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
> should be handled by emblems. This would be in one way simple for
> implementors and theme writers, but on the other hand too restraining;
> can be cases where it's too primitive to simply have a "new" emblem
> 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
> components.. I don't think runtime overlays will be used for this
> but the theme creators can be quite effective with templates(IOW, no
> use of
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
> 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
> 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
> and then all those icon requests result in the same icon. I think it
> 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,
> Short answer: theming of application icons will be possible in either
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
> 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
> not be that obvious. The problem is it requires somekind of
> 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
> 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
> 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
> 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
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
More information about the xdg