From kde-artists  Mon Apr 30 18:57:47 2007
From: James Richard Tyrer <tyrerj () acm ! org>
Date: Mon, 30 Apr 2007 18:57:47 +0000
To: kde-artists
Subject: Re: [kde-artists] Icon naming issue
Message-Id: <46363C2B.6060107 () acm ! org>
X-MARC-Message: https://marc.info/?l=kde-artists&m=117795955126166

If I might sum up my position rather than continue with a non-productive 
discussion.

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 
for KDE.

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

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.

-- 
JRT
______________________________________________________________________________
kde-artists@kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists