[Fwd: [kde-artists] Where to install (new) HiColor icons]

[David Faure]

On Monday 15 May 2006 18:43, James Richard Tyrer wrote:
> I am not talking about making "new kdeclassic icon", I am talking about
> making NEW icons.  Icon such as:
> 	tab_remove_other.png [...]
> which didn't exist before I made them.  And, I am not making KDEClassic
> icons for these *new* icons, I am making generic HiColor icons.

OK, now I understand the issue better.

> Not sure what you mean.  I use my icon them on my system (USR_HiColor)
> and if an icon is missing I want fall back to HiColor,KDEClassic if
> they exist.  I do NOT want CrystalSVG to show up as the fall back unless
> it is the only icon available.

Exactly. And this fallback to CrystalSVG surely happens many times already, 
that the only icon available is the one from CrystalSVG, doesn't it?

> I am not going to make icons for every icon theme that exists to avoid
> installing new generic icons in HiColor so that they can be used as a
> fall back.

But it would work the same if installing those new icons in CrystalSVG.
Let's have one theme that is complete, and that's CrystalSVG.

I understand that from an artist point of view it might be a bit weird, if the icon doesn't
have the "crystal" look at all - but I think this is already the case for many icons in that
theme. It is the default icon theme in KDE, the one which KDE apps install icons into.
I don't see a reason to make an exception for a few icons.

In all practical terms, aren't we just arguing over naming, without any runtime difference?
I mean most icon themes have to inherit CrystalSVG anyway because they can't provide
100% of the icons, right? So let's remain consistent: KDE applications provide
CrystalSVG icons, and icon themes can override that.

> > don't clutter up the hicolour namespace.
> 
> I am (or was) using the HiColor "name space" (icon theme) as the spec
> states it is to be used, as a fall back icon theme (yes the spec says
> "icon theme").  For it to be used as a fall back icon theme, it needs to
> have icons in it.

But not necessarily all the icons. Yes hicolor *can* (according to the spec)
be used as a fall back icon theme, and this mechanism is used for 3rd party apps.
But this isn't the way we use it in KDE, and I think this is where the heart of the
misunderstanding comes from. As Thiago pointed out to me: KDE never uses
"hicolor" directly. We ALWAYS have a theme and that theme is NEVER "hicolor".

Please read https://www.redhat.com/archives/xdg-list/2002-November/msg00073.html
by Antonio Larrosa. "KDE should install an icontheme [...], the hicolor icon theme is there
for app developers who don't belong to a specific desktop. So hicolor should be desktop-neutral,
look-neutral, vendor-neutral."
There was some disagreement from the gnome side (mostly about the "symlink to the default theme" idea),
but really, this isn't the discussion I want to get into again. What we (well, Antonio ;)
implemented in KDE is exactly what the post above describes: the KDE desktop
(i.e. apps in kde svn) install its icons to crystalsvg.

This argument is about "doing something correct per the spec, but unlike what KDE did
up to now" versus "doing things like KDE did up to now, which is also correct per the spec".
I strongly encourage that you do the latter for now.

If you want to change the way things work then we should start by reviving that
xdg-list discussion and coming to a complete agreement about how things should
work, and then we might change the iconloader, etc. We're not at that point, so for now:
please let KDE SVN app install their icons to crystalsvg.

> You appear to have ignored my point which is that if you are using an
> icon theme other than CrystalSVG or KDEClassic and you need the icon
> (for example): "view_fit_width" what should happen?  Should you get the:
> "unknown" icon, or should you get the HiColor icon? 
Depends what your icon theme inherits from. Most themes inherit from CrystalSVG
in order to get the kde-provided icons as fallback. Otherwise they would be broken
since they would lack many icons, wouldn't they?
Even kdeclassic inherits crystalsvg.

> Isn't that what the fall back theme is supposed to be used for: fall back?  
hicolor is the "default cross-desktop fallback", so that desktop-neutral apps work in all desktops.
Konqueror is part of KDE, it should provide icons for the KDE-default icon theme by default.

> If the generic hicolor icon is installed in KDEClassic and HiColor doesn't inherit 
> KDEClassic, then what happens -- what should happen?
The question doesn't make sense in KDE since we don't install icons to hicolor.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).