Icon theme specification: Standardizing icon names
frans.englich at telia.com
Thu Oct 14 01:45:08 EEST 2004
On Wednesday 13 October 2004 21:15, Owen Taylor wrote:
> On Mon, 2004-10-11 at 18:13 +0000, Frans Englich wrote:
> > On Monday 11 October 2004 15:10, Owen Taylor wrote:
> > > Some very quick comments. It's really great you are working on this.
> > >
> > > On Sat, 2004-10-09 at 21:50 +0000, 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.
> > >
> > > Does it make sense to standardize this many icons? Should we try to
> > > standardize a smaller subset that really obviously make sense ...
> > > creating an icon theme with 1048 icons is pretty prohibitive.
> > It is many, but it is what GNOME and KDE needs. It is gnome with the oo.o
> > icons which pops the roof. The question is, since all these icons should
> > be spec'ed at somepoint anyway, it's perhaps just as good to do it at
> > once. In the GNOME case the icons already exists. The trouble of
> > achieving conformance is organizational; to play diplomacy and contact
> > projects, surf repositories, and get all these icons collected in one
> > place -- and with the right names(that diagnosis tool is a must have).
> > The problem is, if we go for something small, it won't work with GNOME,
> > for example. I'm not convinced in this matter and I'll happily see
> > someone clear my confusion.
I think we have the same intentions and goals, but different ideas on how to
practically carry that out.
> My concerns about standardizing 1000+ icons come in several areas:
> - Simply having a big list of names for icons isn't useful; what does
> 'execute-terminal' look like? What does it do? In order to make the
> spec useful for application developers, they have to be able to pick
> an icon based on the icon theme spec.
I haven't copy&pasted from GNOME/KDE -- those icon names which were too weird
or I didn't know what they did, I left out -- we can continue like that.
Rather a tight, correct, small naming theme which is later extended, than a
bloated big theme right now. Of course, should developers be able to figure
out an icon's purpose by looking at its name and eventual description.
What we have to do is to for real go cleaning the names(perhaps after my
second draft), and continue to remove those names which are doubtful, and add
descriptions for those which are vague. For example, "execute" is for running
applications, while "execute-terminal" is for running them in terminal --
obviously those needs better names, or/and descriptions. In other words,
there's a difference between a big list which have clear names and
descriptions, and a big list which is bloated and vague.
> There are two ways of doing this:
> 1) Standardizing the image and requiring all icon themes to use the
> same basic metaphor.
I don't think we should do this -- we want to leave this semantical aspect up
to the theme creators. I neither see how it is important -- it doesn't matter
to application developers which selects what icons to use(they need to find
"an icon for saving file"). The spec is an interface which through icon users
and icon creators should talk about the same icons, and I think that can be
achieved without going into detail how they are design(methaphors, for
> 2) Standardizing the usage with a sentence or two description of what
> the icon is used for.
> Doing either of these for 1000+ icons is a huge job.
No worry :) Those 2000+ icons which was the starting point, were duplicates,
had names which are incomparable to what we have now -- just several years of
collected craziness and chaos. All that huge work of figuring out, looking
them up to see what they do etc., is already done. I won't tell how many
hours I've spent on that -- but I can pull a lot of jokes about icons. I have
in my head what each and everyone do -- give me a phone call while I'm a
sleep. I could add descriptions roughly as fast as it takes for me to type
You have the impression of that the list is inunderstandable and contains
icons which aren't necessary(bloated), but perhaps that would change if I
> - If we are completely unselective about what goes into the icon theme
> spec, maintaining stability going forward is going to be horrible,
> because we won't have any reason for saying no to proposed additions.
Interesting point. But at some point they would have to be added anyway -- the
icon names aren't made up, so we will reach the same level of "detailness"
later on, and the problem of saying no will instead come then(but that makes
perhaps a difference?).
> - I don't think the existence of icons in the default/hicolor theme
> reduces the load on theme creators that much. The current hicolor
> theme icons are largely pretty *bad*, and will look considerably
> out of place in most icon themes.
> One possibility would be to to divide the icon name list into two
> - Core: These icons are required in all icon themes and can be
> relied upon
> - Extra: If an application uses an icon for this purpose, it should
> use the specified name.
> That might reduce my concerns a bit. But in general, I think starting
> small is good. And I think having a set rules for the criteria
> for acceptance and the required definition of each icon beyond the
> name is essential.
Right, it's a draft -- of course they need descriptions. Also, as written in
the top post, several groups needs redesigning.
* Of course, all the names, no matter how many, should reach a level where no
one of us are unsure of what they mean. Those which are doubtable are
* Lets assume we describe all 1000 icons, and basically doesn't remove any,
would it then still be better to aim for a smaller theme? The problem I see
is with migration and implementing the spec: Either desktop environment will
need this big list anyway before they can emigrate. Or do you suggest that it
should happen gradually, that they rename to what the spec covers, and then
install their own home brew icons in addition, until the spec covers it all?
Or you perhaps mean that we should go small as a working method, and not as
> I can't speak for GNOME in general, but from my perspective, I'd much
> rather have the icon name list be genuinely useful for application
> developers rather than just being a superset of all GNOME, KDE,
> and OpenOffice (*) icons.
> (*) Yes, I know the OpenOffice icons aren't in this currently, but they
> would be a natural extension in the future.
Many are left out(for example, those which are attached - GNOME icons) but
especially the text- group has many oo.o icons.
I will do a second draft which incorporates the feedback so far(not
tomorrow..). I can then exclude the more application specific
groups(mentioned in the top post) but I currently don't see how that would
improve the situation, as described above(but they need cleaning and
descriptions in either case, of course) -- feel free to clarify my questions.
-------------- next part --------------
// TODO kdevelop ide
generic/equals // TODO
// emblems ??
// catageory for markers etc.
More information about the xdg