[kde-artists] Icon naming issue

[James Richard Tyrer]

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.

> 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:

http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

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

-- 
JRT