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
_______________________________________________
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
