[kde-artists] Icon naming issue (was: KDE/kdesdk)

[Patryk Zawadzki]

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. 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 shouldbe picked from the parent theme, so again, no need to
search hicolor.

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

Sorry if I failed to follow your way of seeing things.

-- 
Patryk Zawadzki
Generated Content