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 <[EMAIL PROTECTED]> 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.
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
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.
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.
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.
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.
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.
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?
--
JRT
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
