[kde-artists] Icon naming issue
James Richard Tyrer
tyrerj at acm.org
Mon Apr 30 11:57:47 PDT 2007
If I might sum up my position rather than continue with a non-productive
KDE and GNOME need to agree on a standard system for icon themes. Apps
(e.g. OOo) currently install two sets of icons: one for GNOME and one
This standard system should be well thought out and function as a naive
user would expect in all cases. I do not believe that this is what we
have with the current release since I have needed to jerry rig a major
kludge to get icons to work the way I want them on my system.
We must presume that some icon themes will be missing icons and provide
a fall back to a "neutral" icon in that case.
Part of the problem is a bug in the current release. The current spec says:
"The lookup is done first in the current theme, and then recursively in
each of the current theme's parents, and finally in the default theme
called "hicolor" (implementations may add more default themes before
"hicolor", but "hicolor" must be last). As soon as there is an icon of
any size that matches in a theme, the search is stopped. Even if there
may be an icon with a size closer to the correct one in an inherited
theme, we don't want to use it. Doing so may generate an inconsistent
change in an icon when you change icon sizes (e.g. zoom in)."
In the current release, when an icon is available in the chosen theme
but not in the needed size, the search routine will choose an icon of
the needed size in another theme (often CrystalSVG). If this bug were
fixed, many of the problems would go away. If we are going to "add more
default themes before 'hicolor'" then this needs to be user configurable
-- a hard coded fallback isn't going to be satisfactory in all cases.
This would fix many of my problems.
I know how I would do things, but I fully realize that this isn't the
only way to do it. While I will advocate my position in any discussion
(till I hear a better idea). I will support any system that works --
that satisfies the needed design objectives. So, first, we need to
discuss what these design objectives should be.
I read in the spec that:
"It is recommended that the icons installed in the hicolor theme look
neutral, since it is a fallback theme that will be used in combination
with some very different looking themes."
My reading of this is that HiColor is a fallback theme that should
contain neutral ('unthemed', generic, or whatever) icons and that it
should be a full set of icons -- if not a full set, what will there be
to fall back to?
Now, if HiColor is to be a name space to install only default
application icons, that is OK, but I suggest that we call it something
else and/or have another place for the neutral fallback icons.
There is one other point which I did not mention when I said that there
was nothing else to discuss. What do we do when we add a new icon (e.g.
"view_fit_width"). Now we know that every icon theme will be missing
this icon because it is new. So I (or we) make icons in the current
default theme (then CrystalSVG) and the neutral HiColor icons. Where
should they be installed? Perhaps the answer to this question is not
really where they should be installed but how the system could be
Good engineering requires that all possible cases be considered and a
scheme be developed that is satisfactory for all of them. This is not
currently the case with icon themes.
More information about the xdg