Kenneth Wimer wrote:
On Friday 27 April 2007 21:58:27 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
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...
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.h
tm l
Sorry for saying this was a case of misunderstanding, it is not...as you
mentioned in this link the spec says:
' In order to have a place for third party applications to install their icons
there should always exist a theme called "hicolor" '
I am not sure how you interpret this to mean that hicolor should be a full
icon theme on it's own.
DUH!
What I said in the past was based on what the spec said in the past.
<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>
The rest of my reasoning was based on simple logic. If a "fallback"
theme is to be used as such, then it must be a full icon theme or there
won't be anything to fallback to.
If HiColor isn't to be a full icon theme (the spec has now been changed
and so be it) then there must be a way for the icon search to fall back
to something appropriate. I note that if the bugs in the icon search
are fixed so that it conforms to the spec that this will not be as
important an issue. But, there are still users that will install an
icon theme other than Oxygen (one of the Crystal based themes, for
example) and will not want to fall back to Oxygen. All I am suggesting
is that this should be configurable using the Control Center the same as
everything else.
If the bugs are fixed and things are fully configurable, there is
nothing to discuss except for the need for a new generic icon theme to
replace KDEClassic.
--
JRT
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
