On 4/27/07, James Richard Tyrer <[EMAIL PROTECTED]> 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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
