[kde-artists] Icon naming issue

[James Richard Tyrer]

Kenneth Wimer wrote:

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

Yes, a complete icon set should never be presumed, that is why I have 
clearly stated that there needs to be a way to configure multiple fall 
backs.  Multiple fall backs are to be provided based on the theory that 
some icon is better than having no icon (or the "unknown" icon).  If 
HiColor is to be a theme, then these additional fall backs should come 
after HiColor, but if it is to be used only for miscellaneous icons that 
are installed by apps, then these multiple fall backs can come before 
HiColor as the spec says.  What I want is for this to be configurable 
and not hard coded.  If your position is that this should not be hard 
coded, please defend it.

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

Having bugs in the system is not a choice of the desktop, and hard 
coding an icon theme is a very bad choice.  It should work correctly so 
it is possible for a user to choose a theme other than the default. 
Last time that I tried, if you change the "default.kde" link to point to 
something other than "crystalsvg" KDE won't even start.  Perhaps this 
bug has now been fixed.

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

You are, I hope, aware that if a user picks a theme according to their 
needs and the needed icon isn't available in the needed size that they 
get instead a CrystalSVG icon and there is no way to fix this using the 
Control Center.

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

I believe that you have added the word "only".  And (surprise) it still 
says:
<q>
It is recommended that the icons installed in the hicolor theme look 
neutral, since it is a fallback theme that will be used in combination 
with some very different looking themes.
</q>
So, a generic icon theme /could/ be installed in HiColor.  I still think 
that this is the best idea, but there might be conflicts with apps 
installing icons with the same name.  So, it is OK with me to have the 
generic icons installed under a different name as long as there is a way 
to configure the icon search to find them before it finds CrystalSVG (or 
the current default).

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

Bug and a lack of configurability make this very difficult if not 
impossible in the current release since the user will still get 
CrystalSVG icons (and can't change this) even if other more suitable 
icons are available.

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

As I said, there will always be new icons tomorrow and we need a system 
that is designed to deal with this issue rather than hoping that every 
icon theme will have every icon.  In this respect, I am not betting on 
the snow ball (a snowball's chance in hell).

-- 
JRT