Joseph Kowalski wrote:
If this is done users not wanting CrystalSVG icons will get them ONLY
if a HiColor icon does not exist. This is what I, and other users,
expect to happen.
Be careful. You don't speak for this particular user.
I agree with your view that CrystalSGV should not be installing in
the hicolor space. I believe it may be appropriate for
implementations/distributions to add more default themes before
hicolor, but I believe they should consider this carefully.
I emphasize here that this needs to be configurable because I can't see
any setup that would make everyone happy. I don't just mean personal
preference but based on which icon themes will best harmonize with
which. The complaint I see most often is that CrystalSVG doesn't look
good with KDEClassic. I don't think that there is any question that
they don't harmonize too well together.
However you can already do this in a configurable way by the use of:
"Inherits=" statements in the themes: "index.theme" file.
So, I ask if having additional fall back themes before HiColor is even
needed. And as it currently is setup in KDE, it causes problems.
Where we disagree is that I strongly believe the specification is
correct in requiring that hicolor be the last theme checked. If this
is not true, then its no longer the default. It will take just a
few release cycles until the theme(s) located behind hicolor become
the defacto default.
There wouldn't be an issue if all DeskTops shipped a complete HiColor
theme with generic icons (i.e. didn't simply rename icons of another
theme to fill up the HiColor theme). Unfortunately, this is not the
case. Currently, this isn't the case with KDE and GNOME. So, if the
Icon Loader falls back to HiColor, it is quite likely that an icon won't
be found since the generic KDE icons are installed in KDEClassic and the
generic GNOME icon are installed in Gnome. This is the problem for
which I have made one suggestion (having backup themes for HiColor). I
will be glad to hear other ideas on how to solve it. I don't have my
ego invested in my idea. I am an engineer and if I hear a better idea,
I will support it.
Currently, I have HiColor:
Inherits=kdeclassic,gnome,crystalsvg
This works fine because KDE and GNOME don't have the same icon names.
But, FreeDesktop is working on standard icon names and then this is
going to have problems and it would be good if the list could be changed
based on which DeskTop was being run.
More importantly, as an ISV, I want to install an icon that will only
be seen if the distribution hasn't decided to do a "distro theme approriate"
icon *in front* of it: I want the distro to have this opportunity.
Such a "distro (or DeskTop) theme appropriate" icon is certainly what I
would like to see. However, it is better to fall back to the HiColor
theme which is supposed to be generic (sometimes incorrectly referred to
as "unthemed") than to use an icon from a theme that strongly clashes
with the user's selected theme (e.g. if the user has selected
KDEClassic, it would be better to use the generic HiColor icon than to
use a CrystalSVG or CrystalClear icon).
--
JRT
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
