[kde-artists] Icon naming issue

[Kenneth Wimer]

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

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

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

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

Everyone else seems to realize that hicolor is a place for apps to install 
their icons - nothing more. For some reason you seem to insist on having 
hicolor be a full blown theme of it's own.

Ken