Icon Name Standardization, second draft

[Rodney Dawes]

On Mon, 2005-03-28 at 22:47 -0500, Andrew Conkling wrote:
> 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?

It is impossible to provide a canonical list of all icons at all times,
for which one must use to be compliant with the theme. However, we can
try to cover all the generic bits, and specify how more specific icons
should be named, so that fallback to the generic icons works correctly.
That is the goal of this spec.

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

Use symlinks, rather than copying the files. This can save quite a bit
of space for icon themes.

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

Aliasing really belongs in the Icon Theme and MIME Type specifications
themselves, rather than in the Icon Naming Specification, I think. The
aliases aren't there to say that something should be named some way.
They should be meant to allow theme authors to create one image, and
specify legacy names for that icon, that apps may still use, so that
we don't have to copy icons around or create symlink farms, to make the
desktop look proper when using the theme. I will be working on a patch
to the Icon Theme spec, and to gtk+ as well, for implementation value,
to do something like Provides=foo,bar for the .icon files.

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

One of the purposes of this spec, is to list all the generic icon names,
as well as many of the more specific names. However, I am not sure how
best to distinguish the two, in the docbook source for the spec.

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

If this is happening in GNOME, then it is a regression, and you should
file a bug report. The panel used to have code to strip the extension
and path off of an icon's filename in the desktop files, for looking up
in the icon theme. If no icon was found in the theme, it would fall back
to trying to use the full path as specified in the file. I'm not sure
what KDE does here, though.

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

They should follow the guidelines for creating new icon names, and, if
possible, ask for review of the name, and inclusion of the name, in the
spec.

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

Ideally, if an application is going to create their own icon names to
use, then they should probably be providing those icons in some way, and
falling back to them, if no icon was found in the theme. Given that, the
goal of this specification is to provide a standardized list of names to
use for icons in applications and themes. As a theme author, the generic
icon names specified in the icon name and description tables, should be
the ones that you are most concerned with. Hopefully, I can figure out
how to distinguish between generic and extended names in the spec, soon.

I recently sent a seperate specification docbook file to xdg list, but
it seems to be still waiting for moderator approval, as the docbook is
slightly above 40K in size. Jakub had pointed out a couple things, so
perhaps I will make those fixes, and send it out again, compressed, or
on a web server somewhere.

-- dobey