Icon Name Standardization, second draft

[Andrew Conkling]

Hi folks,
I'm glad to see that there are a handful of people ostensibly interested
in getting an icon theme spec underway.  I've been contributing to the
GTK+ portion of an icon theme (Lila: http://lila-theme.berlios.de) and
that's been enough work, let alone trying to carry such efforts across
DEs.

As such, I approach this topic from a themer's standpoint, for better or
worse.  After reading the spec, a few things come to mind that will need
to be addressed.  Please bear in mind that I have very little knowledge
of KDE and its theming.

1. I'm not sure of the state of the "Standardized Icon Names", but
offhand I know that there are a number of names used by apps that are
missing (namely stock icons).  I'm assuming this list is incomplete?  Is
it meant to be (eventually) a list of centralized names to which apps
will have to conform to be themed properly?

2. Many times I have had to copy an icon file to a new name just for one
app's errant naming.  For the Lila project, we have aimed to be
complete, but this means, for example, that we end up having a half
dozen "Close" icons with different names.

Might I propose an alias layer to these themes?  For example, anyone
familiar with GTK+ theming knows the iconrc file tries to take care of
this to some extent.  The problem is that they are bound to the GTK+
theme, not to the icon theme.  If we could have some of this
functionality in icon themes, it would go far to easing transition to
conformance to this spec.

We could go ahead and make a short list of icons (yay, designers have a
less daunting task, i.e. fewer icon files to make) and our apps will
still be themed properly (yay, users can enjoy the themes), even though
they may refer to the icons using deprecated names (yay, app developers
don't have to rush to conform).  Seems like a win-win.  If we like this
idea, we can discuss details later; I just wanted to throw it out there.

3. I know it's blurring specs, but icon themes only work (at the moment)
in menus if .desktop files refer to icon names implicitly, e.g.
Icon=firefox instead of Icon=firefox.png or
Icon=/usr/share/icons/hicolor/48x48/apps/firefox.png.  I think something
should be mentioned to this end because many distros roll their
own .desktop files that trash an icon theme's ability to work.

4. What happens when an app has a good reason to add an icon not
specified?

5. Assuming #4 will happen, can we make some mention of some explicit
communication between the developer and the themer?  A handful of times,
I (not a developer) have been told to muck around the code looking for
icon names to theme (even with such a big project as Evolution).
Something like this would be nice to add to the "Conformance" section:
"Any icons you deem to add must be documented and distributed with the
source."

Of course, we'll have to preface that heavily with discouragement on
doing so. :)

So there are my (rather) skewed comments and reflections.  While I
haven't really touched on some of the questions and comments others have
made, in many ways mine are the same questions and issues that got me in
touch with Frans in the first place.  While this spec is a big step in
the right direction, it still has room to improve as far as this themer
is concerned.

Let's make it great!

Warm regards,
Andrew Conkling