[kde-artists] Icon naming issue

[James Richard Tyrer]

Kenneth Wimer wrote:
> On Friday 27 April 2007 21:39:48 James Richard Tyrer wrote:
>> Patryk Zawadzki wrote:
>>> On 4/27/07, James Richard Tyrer <tyrerj at acm.org> wrote:
>>>> As I see it, the problem is that we don't have a proper set of
>>>>  HiColor icons.  Someone moved all the existing HiColor icons
>>>> to KDEClassic and for some reason all new HiColor icons were 
>>>> removed. Then some HiColor icons were renamed CrystalSVG and 
>>>> some CrystalSVG icons were renamed HiColor.  Now GNOME seems to
>>>>  have emulated us and removed their HiColor icons as well.  To 
>>>> me this is a real mess.
>>> Why is this bad? Apps drop their default icons to hicolor so 
>>> these are picked up regardless of the theme in use.
>> HiColor is not "default", it is fallback.
>> 
> 
> Semantics

That was my point.  This semantic issue has caused a lot of confusion.
> 
>>> Why should any theme put its icons there? If a theme is complete,
>>>  no icons will ever need to be searched for in hicolor. If it is 
>>> not complete, it should provide its own list of parent themes 
>>> (e.g. "based on CrystalSVG") and the missing icons should be 
>>> picked from the parent theme, so again, no need to search 
>>> hicolor.
>> While I half agree with you, the point here is the standard:
>> 
> Again, semantics...
> 
And here, I totally fail to see your point.

>> http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.htm
>>  l
>> 
>>>> The icon search is supposed to fall back to HiColor.  The 
>>>> problem is that now neither KDE nor GNOME has a set of HiColor 
>>>> icons to fall back to.  The answer to this should be obvious 
>>>> (and it needs to be added to the standard).  We need to have a 
>>>> list of secondary backup icon themes that will be searched when
>>>>  a fall back to HiColor doesn't find an icon. I suggest that 
>>>> this be in a file so that it can be easily changed (or changed 
>>>> by the user).
>>> Why do you think a list like that would be needed? I see hicolor 
>>> as a place where apps can drop their default icons so they work 
>>> regardless of the theme in use.
>> Since HiColor is no longer considered a theme, these "default" 
>> icons often don't exist.  It will now allow an application to 
>> provide a generic set of icons which will be used (as a fallback) 
>> no matter what theme the user has selected, but it doesn't address 
>> the issue in this thread which is what should happen when an icon 
>> theme is missing icons.
>> 
> If the default theme for a desktop is missing icons the answer would 
> be to create the missing icons for that default theme.
> 
And the answer to bugs in the code is to write the code correctly the 
first time. :-D  This is not an answer anymore than walking on water is. 
  Icon themes will always be missing icons.  Even if they are all 
complete today, new icons will be added tomorrow.  There must be a 
satisfactory method of dealing with icons missing from a theme.

>>> If a desktop icon theme is missing some icons and it does not 
>>> provide a parent to interrogate for the missing bits, then I 
>>> consider the theme to be broken, not the icon spec/desktop.
>> The problem with that is that the user's Desktop knows which icon 
>> themes are installed and there is no way for an icon theme the user
>>  installs to know that.  The recent changes to the icon theme spec 
>> don't change the fact that we need a generic icon theme to fallback
>>  to.  Not using "HiColor" for this them has only further confused 
>> the issue.  Since the Icon Theme Spec no longer specifies the name 
>> of this them, we need for this to be configurable.  This current 
>> issue illustrated the need for this.
> 
> The answer, as I see it, would be to do as kde has done and to 
> fallback to the desktop default theme.

This proved to be very unsatisfactory since CrystalSVG icons looked very
out of place in almost all other icon themes that were not Crystal type. 
   Others have complained loudly that they don't want CrystalSVG icons 
dropped into a DeskTop with Oxygen icons.  They are correct about this 
issue.  However, that issue is a general issue that needs to be 
addressed for all icon themes that a user might install.

Part of this issue was a bug; did NOT fall back to the default theme as 
indicated by the link: "default", it fell back to CrystalSVG and this 
was hard coded.  The link: "default" was redundant since it could not be 
changed to point to another icon them.

> In earlier kde's this was crystal, in newer versions it would be
> oxygen - the point that you disagree with so much. A desktop pics a
> default theme for a good reason. If you do not like that choice you
> are surely free to build your own system which does exactly as you
> like.

If a DeskTop picks a default icon them for the reason of forcing 
everyone to use it, as appeared to be the case with CrystalSVG, this 
most definitely NOT a good reason.  To say that everyone that doesn't 
like the default theme should build their own system is the height of 
arrogance.  Does this also include visually impaired users?  Perhaps you 
should post to KDElook that people should stop making other icon themes.

What is needed is for KDE to work correctly according to the spec, and 
for all icon themes to be equal (and one of them specified as default) 
with the exception of the HiColor fall back.  If you don't know what I 
mean by this, it means that if you select (for example) KDEClassic that 
the code shouldn't drop CrystalSVG icon onto your DeskTop without being 
asked to do so.  The default icon theme should be the same as any other 
default; the user should be able to easily change it by using the 
Control Center.
> 
> Everyone else seems to realize that hicolor is a place for apps to 
> install their icons - nothing more.

Perhaps it has now been changed to be that, but that is not what the
spec used to say.  If this is now what HiColor had become, then we need
some other way to have the icon search look for a generic icon.

> For some reason you seem to insist on having hicolor be a full blown 
> theme of it's own.

And my reason for insisting on this was that that was what the Open
Desktop Icon Theme Spec said.  I think that this was a good reason for
doing so.  Now that the spec has been changed, the issue of the need for
generic icons remains.  Or, as I said above, is it the intent to force 
all users (even the visually impaired) to use the default icon theme?

-- 
JRT