[kde-artists] Icon naming issue

[Kenneth Wimer]

On Friday 27 April 2007 22:41:17 James Richard Tyrer wrote:
> 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.
>

In this case it was a small issue causing a bit of confusion, nothing more.

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

This is addressed in my second mail attempting to clarify my point so I won't 
go into it again in this one.

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

You say yourself that icon themes will never be complete...so the hicolor 
theme you desire also fails in this way...not sure what you want exactly.

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

This was a choice of the desktop in question and there are good arguments for 
this, I have previously stated.

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

Visually impaired users should pick a theme according to their needs. Ideally 
the install routine should include an option for these users to get the icon 
theme they need after install but this is not an issue of this list (at least 
not yet).

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

But as the spec clearly says hicolor is only a place for apps to install their 
icons. 

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

 It has been this way for a very long time, if not from the beginning (not 
sure on that though).

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

Read the spec and show me the words that say this. Again, users with special 
issues should pick a theme which applies to them. No desktop that I know of 
makes the visually impaired their target group and therefor their default 
icons are not necessarily perfect for that sub-group of users. 

The real answer would be to have a complete icon theme for visually impaired 
users selectable but not necessarily default.

Ken