Icon Name Standardization, second draft

[Frans Englich]

Hello all,

Finally, here's a second draft of the icon name standardization. Attached is a 
patch against the docbook source in CVS. I will follow up this post with an 
XHTML rendering. I'll provide a diff against the previous patch applied, on 
request.

The previous draft, posted a long time ago, can be found here:

http://lists.freedesktop.org/archives/xdg/2004-October/005084.html

What follows is a list of changes done compared to the previous draft, 
combined with discussion:

* Added a "Conformance" section. What it currently says is vague, and more 
areas could be mentioned, but the concept mentioning conformance probably 
needs to be aired first.

* All device icons were namespaced with "device-".

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

* Standardized application names were removed. It wouldn't surprise me if it 
was re-added in the future, but it's still too difficult to pull off, is a 
complex matter(and questionable too, perhaps), and it can wait because it's 
not the most crucial.

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

* The names can by no doubt still be improved by additional removal and 
renaming. 

* They all need descriptions. This is important because they're still a list 
of names whose representations are unclear and hence open for interpretation.

* The spec needs a top level section discussing inheritance, IMO.

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

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

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.

Personally, I'm not sure about that. What's interesting is the large picture, 
not what a piece of paper says. In KDE there is a large collection of flags, 
and excluding the coverage from the specification does not solve a single 
flag issue for the distributors who ship KDE, for example.

I don't think it's possible to "ban" various usages. No matter how it's turned 
and twisted, uncomfortable usages from one point of view will exist; country 
maps in the geography learning program KGeography, for example.[1]

The reason to why I want coverage in the specification, is that I think it is 
the easiest way for distributors to make others opinions fit their's. Instead 
of patching individual projects and trying to convince them of their views 
and ensure it stays that way, they can just install a theme at their 
preference. I think that's easier, less friction, and more relaxed.

Practically, one way of implementing it is to add support for flags as an 
optional set of names per country, not language, following the pattern 
"flag-[XX]" where XX is the country code as per ISO 3166[2].

What interests me is how a rejection of flag names fits into practice. Does it 
sound like this?

"Any usage of flags is wrong. The specification should not be extended with a 
flawed concept. Instead, any usage of flag icons in relevant open source 
software should be removed. And that will people agree to, and it is easier 
than to add any mechanism to the specification."

That is perhaps the reasoning which accompanies the opposition of flag names, 
I don't know. Feel free to comment.

		***

The largest change was the removal of a vast amount of names. The initial 
draft had about 1000 names; while that's not unreasonable for a complete icon 
theme, it's too much for reviewing. So, as demanded, is more specific icon 
names such as for pim, office, image-manipulation etc, lifted out. It does 
not enough to cover for example kdebase, but this draft is possible to work 
upon.

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

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.

KDE artists; Kenneth, Jonathan, et. al, would KDE 3.5 be switched by anyone if 
a spec within a reasonable timeframe arrived?

As a KDE developer, I have unfortunately too little insight in GNOME and other 
projects -- CC to whom it matters, of course.


Comments, ideas, are appreciated,

		Frans

1.
One can see it from another perspective too. Len Bullard expressed the opinion 
on xml-dev that what W3C should do is not innovate but standardize what the 
industry, with its natural amount of failures, have developed into a stable 
result and has proven to have a demand. The XDG specifications are supposed 
to solve problems in the reality, and it doesn't kindly adopt to whatever a 
group at a standardization body thinks is best. The best one can do is to 
make ones own(as in distributor) interests fit as good in as possible with as 
little friction as possible.

2.
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iconNameStandardization_2.diff.bz2
Type: application/x-bzip2
Size: 5109 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050324/58715800/attachment.bin