[kde-artists] Icon naming issue
James Richard Tyrer
tyrerj at acm.org
Fri Apr 27 14:24:04 PDT 2007
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
>> 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
>> 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
I believe that you have added the word "only". And (surprise) it still
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.
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).
More information about the xdg