Icon Name Standardization, second draft

[Rodney Dawes]

On Thu, 2005-03-24 at 04:08 +0000, Frans Englich wrote:
> Hello all,

> * Small fixes, a heap of names were sanitized, and spelling/phrasing fixes in 
> the spec not tied to icon names(perhaps it conflicts with Rodney's recent 
> patch).

The fixes to various parts of the Icon Theme spec should be implemented
and sent as a separate patch. They have no relevance to the naming of
icons, and make the patch a little more difficult to read.

> * The emoticons in the Symbol category were removed; this was discussed 
> recently on this list, and needs a new take if to be part of this spec(which 
> there are many advantages of).

I don't think shoving some random subset of icons, into a category
called "Symbols" is a bit redundant. All icons are symbols.

> * Names for MIME icons is a separate issue; if we can split things up into 
> small steps it's probably a good idea. Start a separate thread about MIME 
> icons, if of interest.

MIME types are perhaps one of the most important aspects of
standardizing icon names. They all appear in the file manager, among
other places, and are the most prominent users of icon sizes above 24px,
making them much more visible to the user.

> * Since it likely will be brought up: I don't think a concept of optional 
> name-sets makes sense in practice. If icons are needed they're need, it's 
> that simple.  Since the icons exists if they are required, it's a matter of 
> refactoring(e.g putting the icons in a theme instead of the application 
> package), and themes can reach full coverage in practice by inheriting from 
> large base themes such as crystalsvg, if they cannot provide them themselves. 

It does make sense. You need to not require artists to create 30000
icons to make a reasonably complete theme. Most artists don't have that
kind of time. Most icons can be genericized enough to reduce the number
of icons that needs to exist, to a much smaller number.

> That was the details, left is two large changes: the removal of flag icon 
> names, and the (temporary) removal of a large set of names.
> 
> 		***
> 
> The country-flag icons were completely removed. Judging from the previous 
> discussions a majority of people found various reasons for not having them. 
> It appears that people are convinced the complications of flag-icons are 
> avoided if it's not covered by the specification.

"Standing aside to do nothing, is just as bad as pulling the trigger."
We can solve the problem, and avoid the political issues at the same
time. The point of the naming spec should not be to provide a canonical
list of all possible icon names. That is just not a feasible goal. We
need to set the standard for how icons are named as well as what the
base set of icons is named.

> All icon names that was removed have been placed in the attached file 
> "removedNames.txt", and it is probably a good base for constructing name sets 
> from, since its names were derived from GNOME's and KDE's icons(see the 
> initial draft for details).

No such file has been attached.

> There's been interest for getting this spec in the direction of finished, but 
> I wonder why :) It's relatively quickly done to bring a theme to conformance 
> once a stable version is released, but that's not useful before any of the 
> major desktop environments have switched, AFAICT.

It's useful because it means artists will then have a canonical list to
go by. If all the themes migrate to it first, then it helps to push the
applications to migrate as well.

> Comments, ideas, are appreciated,
> 
> 		Frans

Firstly, as stated before in reply to earlier drafts, this does not
belong in the Icon Theme Specification itself. It needs to be a separate
specification, which is referenced by the Icon Theme Specification, and
strongly encouraged by.

Secondly, I will agree that the Icon Theme Specification needs to
explain Context a little better. However, Context is not a reliable
method of looking up an icon name. It needs to either be required by
the spec for doing lookup of icons, or removed. In its current state,
it is pretty unusable. I think FileSystems is a context which needs to
be removed as well. All of the icons in it really belong under mime
types, as far as I can tell. And, as I stated earlier in this mail, I
think "Symbols" is overly redundant, as all icons are symbols.

Your patch also seems to have a large comment section as a reference for
how to name icons. The scheme for naming icons needs to be defined as
part of the specification itself, not as guidelines in a comment for
future self-reference, when updating the spec.

In reference to the comment block, however, there are also some other
issues. It should state that icon names should be created in the "POSIX
C locale" and not "with American spelling". The list of allowed
characters should not be restricted to lowercase alphanumerics and the
dash or hyphen character. Underscore, period, plus, and possibly the @
symbol, should be allowed as well. And, icons which aren't actually
Actions, should not be in the Actions context. They should be
categorized more apprporiately. For instance, the "category-*" icons
should be in a "Categories" context, and the "category-" prefix should
be stripped off.

Another good rule to follow, is that not all items should have icons.
While icons are pretty, too many can be overwhelming to the user, and
distract from what is trying to be found. This goes back to the Generic
vs. Specific argument. While it might be nice to have icons for all of
your various tape drives, memory card formats, and everything else, it
doesn't make sense for most users to have them. The most important thing
we need to do in this spec, is to define style. The content will come
much more easily then. For example, see:

http://www.gnome.org/~dobey/icon-names.txt

vs:

http://www.gnome.org/~dobey/icon-names-minimal.txt



-- dobey