Icon theme specification: Standardizing icon names

[Frans Englich]

Hello everyone,

Attached is a patch which standardizes 1048 icon names, compiled from the 
~2050 icons which KDE and GNOME in all houses. While that sounds like a lot, 
and bizarre for that matter too, the important question is where this is 
heading, what we want to achieve, and why.

Is an icon theme of interest? Is it important?

In order to achieve one of the goals we in general aim for -- seamless 
integration across desktop environments -- standardized icon names is 
important because it is the second half of the "look" part in look&feel, next 
to widget themes. It allows Open Office to use the crystalsvg when run in 
KDE, KDevelop to use GNOME's icons -- or GNOME to use crystalsvg, and vice 
versa. Apart from how nice that would look, it also makes it trivial to 
simply switch icon theme to another of personal taste or being special 
designed for accessibility, as well as it opens up the competition, leading to 
a better end result.

Is it possible? If one project has one icon usage which isn't is covered by 
the icon theme, won't that break it?

Yes, it would break that application. If a project ignores the specification, 
or if it is impractical to cover all possible icon usages(not obvious), it 
means there is holes which are missed by all the advantages of having an icon 
theme. However, I think it is possible to cover the vast majority of usage 
scenarios -- basic desktop environment, office applications, PIM, instant 
messaging, email, and so forth.

How many names that are covered beyond the common ones(and at all) is a 
question of interest: Icons needs to be created anyway, and if there's no 
interest for making sure they are put into the relevant theme, and if 
coordination with the specification doesn't takes place -- then there's 
simply no integration for those usages.

Is it possible to freeze time -- the icon names -- with a political system 
like this specification?

While the middle application layer and graphical interfaces has a peak in 
productivity and large changes perhaps right now, it will at some point start 
to settle down, and until then, the specification simply will have to be 
systematically extended.

How is the transition done, and what about backwards compatibility?

Since every use of an icon has an icon name hard coded, it means that any 
change in naming scheme requires the code to be adapted to the naming scheme, 
as dictated by the specification. Someone said the specification could match 
previous names to ease transition -- good luck -- because squeezing more than 
1000 identifiers into one namespace while trying to keep the names somewhat 
understandable is hard enough as it is. Also, I think a systematically named 
theme is to be valued high, since it will stay for long, be extended, and 
that we have the chance to do it properly from the ground up, at the cost of 
a one time upgrade.

I first thought of adding a transparent compatibility mechanism which mapped 
old names to new, but Kenneth Whimer convinced me on this list it was a bad 
idea.[1] However, after a second thought, it do allow transition to happen in 
two stages: the toolkit can start, then applications, and then the 
compatibility layer is removed, and hence it can happen out of sync.

		***

Assuming now a name standardization is of interest, I will introduced what the 
attached `icon-name-standardization.xhtml.bz2` more specifically contains, and 
why. It's the specification rendered into XHTML, I will post the patch 
afterwards(too large together for the list). New sections are "Standardized 
icon names" and "File Formats/Context", and the context Symbols is new.

The names are built from KDE's kdelibs/pics/crystalsvg, and GNOME's 
gtk+/gtk/stock-icons and gnome-icon-theme. 

Where is the line drawn -- what should be covered? 

I think more or less everything can be covered, but if we try to do it at 
once, it will fail for two reasons: 1) Developer buy in, a threshold of say 
2000 icons is tough; 2) It is hard to get it right without having a sober 
view of what is actually a demand -- an incremental development approach 
would ensure only needed icons are added.

That suggests we should start small and conservatively.

The crucial part is to select names which are good, and relevant, because new 
ones can always be added, but not changed or removed. When I waded through 
the existing icons, I found many which were duplicates and 
inunderstandable(dust from many years..). Icons which were too weird were 
excluded and can be added at a later point, if of interest(rather that, than 
bloat).

In either case needs many of the icon groups to be reworked: pim, im, image, 
math, among others. The current ones are too narrow, and what needs to be 
done is to investigate/work with the major projects out there -- KDevelop, 
Evolution, KDE PIM, Quanta etc. -- so that the namespace is suitable for 
everyone. This is time consuming and quite boring, just as the current 1000 
icons, and requires at least shallow insight. I currently don't have this(as 
for about 300 GNOME icons which still are left, mostly oo.o), and I thought a 
check point first, could be a good idea.


		***

Random small practical issues:

* A "pseudo icon" mechanism is clearly needed. One reason to the huge amount 
of icon names is that either KDE or GNOME, but seldom both, has many 
different icons in particular areas, and hence the numbers goes to the roof. 
There is no problems with creating an icon theme which have not that detailed 
distinctions, and the count could probably drop with 100-200. This would not 
only be practiced in the common case(GNOME and KDE), but could also be a 
design choice to explicitly have icons look similar and simple. 
One option is to simply copy icons around but that's not maintainable. Another 
is to create symlinks, but that doesn't work on Windows, and is also 
cumbersome. The solution, AFAICT, is to have an IsAlso directive in the icon 
data file, which lists icon names which the icon also "is"(but this is 
complex). This have been discussed before[2], perhaps the icon-slicer is the 
solution for this, as Owen says. A solution on this is mandatory, AFAICT. 

Depending on how that "pseudo" mechanism is implemented, it could be used as a 
compatability layer. A theme, which inherits from hicolor, maps old names to 
the new ones, and KDE&GNOME's themes inherit from that compat theme, and then 
switches back to hicolor when they want to skip compatibility.

* Many icons which were of filesystem type, especially in KDE, are mimetypes 
in the shared-mime-info. This is taken into account, but there's still vague 
cases: should a temporary file be a mimetype? What about hidden files? It 
would be practical from an implementation perspective, AFAICT.

* Both GNOME and KDE has folder icon of various colors. I should just add a 
bunch of arbitrary ones to the filesystem context? (and then there's the 
inode/directory mimetype) Or want people to switch to overlays in some way 
while the chance is here?

* Throwing this thought out: At some point(if not already), animations will 
become central and the exact same issues with respect to theming will emerge. 
It could be a good idea to be ahead of time.

* KDE has for device icons always two versions: foo_mount and foo_umount, 
while GNOME doesn't. I have not included it in the spec, because it sounds it 
could be solved in a better way. If it should be used at all, overlays are 
probably better. What should we do with this? (Kenneth?)

* There's a big difference between how GNOME and KDE handles folder 
attributes. GNOME uses "emblems" as overlays, partly in its spatial browsing 
concept. KDE has the "folder reflects content" feature and indicators for 
read only folders, for example. KDE doesn't use overlays, but use ordinary 
folder icons modified by hand. Should we agree on a method for this? (I would 
say KDE should switch to overlays and the emblem group to be extended) Or 
should we have emblems as well as folders like KDE do?
It should also be asked if scaled mimetype icons(as overlays) should be used 
instead of emblems, especially for KDE's "folder reflects content". Otherwise 
it will be an endless adding of emblems.

* Since it may be of interest to theme application icons, it means 
applications themselves should install into hicolor, and not crystalsvg, 
which is the widespread case in KDE(but GNOME is good at it too). This needs 
fixing.

* At random the spec contains "new" actions for various file types, for 
example folder-new and spreadsheet-new, etc. Probably will new cases sprinkle 
up regularly, and couldn't it be a good idea to have a pattern/system for 
this? If we get MIME categories, we could have a naming scheme of "[MIME 
category icon name]-new".

* In the patch there is standardized application icons for common ones, which 
allows simple programs to easily be themed, without having to bother with 
individual applications(but this can also be solved with pseudo icons). Is 
this a good idea or would it only be ignored?

* GNOME have "rtl" versions of some icons, for example "stock_revert" and 
"stock_revert_rtl". The rtl images are horizontally flipped, for bidi 
languages I assume. KDE doesn't have this. How should this be handled? 
Should the spec dictate the lookup code to be "load *_rtl version if it exists 
and if bidi language is used"? This means a stat for each loaded icon. Would 
it be better to have a directive in the icon data file, which simply told the 
icon loader to flip the image? (simpler, smaller icon theme, among other 
things)

An icon theme spec would obviously separate toolkit from the icons. It would 
be natural to package them separately, because of the usual arguments of user 
choice and developer flexibility(applications would depend on a toolkit which 
in turn would depend on a virtual icon theme package). While it may sound 
theoretical, pressure will probably come later on. It could be a good idea to 
start that separation, so it's already done. It would also help to avoid the 
toolkit and icon theme to grow back together, and ensure the icon theme's 
abstraction/relay role is kept by making it more difficult to bypass the spec.

The number of icons shouldn't be that frightening because they already exists. 
The problem with getting this spec adapted and working is of organizational 
art. (for GNOME & KDE)


Promoting Adoption
------------------
The spec needs attention and focus in order to be followed, that projects 
cares about it and ensures it gets updated, instead of ignored. One way to 
ensure that focus and pressure exists, is to get a lot of people to value it. 
This can be achieved by leveraging the specification and making it easy to 
create icon themes, because from it emerges a user pressure, which then goes 
whining/filing bug reports at projects which doesn't follow the spec -- and 
there comes the conformance. That community("look&feel"/power user) is also 
very large and "ardent", and hence a strong resource.
Similarly, the easier it is to create functioning themes, and the bigger 
chance that themes simply works -- the bigger is chance this tricky spec gets 
adopted.

I think these aids can promote adoption:

* Icon theme howto
* Diagnosis tool for theme creators
* Theme-package template


*** Icon theme howto
Icon theme creators need to know technical aspects, but far less than what the 
Basedir and Icon Theme specification contains. This howto could be a Docbook 
article available at free desktop, which pulls in the icon names with 
XIncludes(to avoid copy/paste), does a pragmatic discussion, and outlines 
do's & don'ts for creating icon themes. It could contain a FAQ section and so 
forth.


*** Theme-package template
In order to save people from build system hazards, we could provide a package 
template which has all that already set up. 


*** Diagnosis tool for theme creators
Ensuring that icon themes complies with the spec, isn't easy considering the 
size. A diagnosis/regression tool could help keeping an eye on compliance. 
KDE/GNOME would probably need it anyway. Implementation suggestion:

A simple program in Python takes an icon theme name as argument, and produces 
an XML file containing information about what was found in the XDG path. It 
then calls xsltproc which with an XSLT compares it to what names that is 
allowed as according to the spec, and then produces an output file, which at 
a second stage is transformed to xhtml(content/style separation). How does 
the diagnosis tool know what names that are allowed? At build time, the icon 
names are with XIncludes extracted from the Docbook article to a data file, 
and then it is installed.

The tool would report "The theme 'foo' conforms to theme spec 0.8" 
alternatively "... does not conform because: ...", where the error reported 
could be missing icons, and surely other things which can be reported; KDE 
have an ever ending problem of randomly missing sizes.


What needs to be done?
----------------------

The above issues must be solved, especially what names to use. Other than 
that, it's probably a good idea to prioritize the diagnosis tool, howto, a 
small spec(e.g. less than what I've compiled), and get that out as soon as 
possible.


Ok. I need some distance to this -- pull me down to the ground.


			Frans


Footnotes

1.
http://freedesktop.org/pipermail/xdg/2004-September/004821.html

2.
http://freedesktop.org/pipermail/xdg/2004-July/004232.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: icon-name-standardization.xhtml.bz2
Type: application/x-bzip2
Size: 12766 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20041009/c256f7e2/attachment.bin