Icon theme specification: Standardizing icon names
frans.englich at telia.com
Sun Oct 10 00:50:42 EEST 2004
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
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. 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
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, 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
* 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
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)
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
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
*** 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
Ok. I need some distance to this -- pull me down to the ground.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 12766 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20041009/c256f7e2/attachment.bin
More information about the xdg