Icon Name Standardization, second draft
frans.englich at telia.com
Thu Mar 24 06:08:48 EET 2005
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
The previous draft, posted a long time ago, can be found here:
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
* 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
* 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.
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.
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
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,
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5109 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050324/58715800/attachment.bin
More information about the xdg