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

Tue May 16 18:49:53 BST 2006

David Faure wrote:
> 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?

That is what should happen if a generic (HiColor) icon isn't available.
  However, Crystal Style clashes badly with many available themes.  If a
generic icon is available, the fallback should be to that icon.

>> 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 am making both CrystalSVG and HiColor icons for the new icons.
Obviously, I installed the CrystalSVG icons as CrystalSVG.  The question
is where to install the HiColor icons.

This isn't very clear:

http://developer.kde.org/~larrosa/iconthemes.html

but my reading of it is that a generic icon is to be installed as
HiColor and a CrystalSVG icon is to be installed as CrystalSVG and
(optionally) other icons of other themes can also be installed.

> 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.

The only exception is that it appears that I am the only one making the
required generic HiColor icons.  All new icons should be made both in
the current default icon theme and also in HiColor.

> 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.

As the final backup, the icon loader should look in the current default
(which should be referenced as "Default" rather than CrystalSVG so it
will change if the default changes).  My recommendation is that to meet
the specific situation in KDE that the Icon loader should search in:

	1.  Chosen icon theme and its inherited themes
	2.  HiColor
	3.  KDEClassic (if the app's desktop is KDE)
	4.  Current Default for the app's desktop (CrystalSVG in KDE)

This will implement the intent of the spec to find a generic icon (if
available) but use the current default as a final fallback so that some
icon will be found if available.

>>> 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".

Yes, that has been discussed and although GNOME uses HiColor directly, I
accept FE's suggestion that I make a wrapper icon theme to use HiColor
first and then KDEClassic with a final fallback to the current Default.
  Unfortunately, it doesn't work [see my post of 04/27/2006 07:58 AM to
the  artist list].

> 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.

I believe that he makes my point:
<quote>
2) Another situation is when a desktop installs just the apps icons to
hicolor (as Alexander proposed):
Leaving aside the problems I already said with this (duplicated icons or
some icon themes splitted over different icon theme directories, which
is non-logical IMNSHO), I saw a new problem with this (and an important
one if we want to cooperate).
<quote/>
I also assert that installing CrystalSVG icons as HiColor is a bad idea.

> 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.

What KDE has done up to now is to install some CrystalSVG icons as
HiColor and install some KDEClassic/HiColor icons as CrystalSVG.  Both
of these actions are bad ideas.

But, I can't do either of these things since it is my intent to make
both HiColor and CrystalSVG icons.

> 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.

Yes, there are some issues which should be posted to the xdg-list.  The 
issue I have is with this:
<quote.
The lookup is done first in the current theme, and then recursively in 
each of the current theme's parents, and finally in the default theme 
called "hicolor" (implementations may add more default themes before 
"hicolor", but "hicolor" must be last).
<quote/>

This needs some discussion.  Not just the wording but other issues as 
well.  This doesn't work for KDE since most of out HiColor icons are 
installed as KDEClassic, and KDEClassic is missing many new icons.

> We're not at that point, so for now: please let KDE SVN app install 
> their icons to crystalsvg.

For the new icons, I am making *both* CrystalSVG and HiColor icons (as
larrosa requested).  I installed the CrystalSVG icons as CrystalSVG and
the HiColor as HiColor.

The issue here is that JR seems to think that *new* HiColor icons should
be installed as KDEClassic.  If that is done, these HiColor icons will
not be available for fallback use for themes other than 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.

Why they do this, if in fact they do, is a mystery since with the
current bugs and design issues in the icon search algorithm CrystalSVG
icons will be used anyway.

> Otherwise they would be broken since they would lack many icons, 
> wouldn't they?

As I (and I think larrosa) said, the current Default (whatever is
pointed to by the link: "default.kde" should be used as a fallback for
KDE apps.  I think that it should be used after HiColor and KDEClassic.
  If a theme wants to inherit CrystalSVG first, and explicitly, that can
be put in the: "index.theme" file.

> Even kdeclassic inherits crystalsvg.

This was the case and it is a big mistake.  KDEClassic should inherit
HiColor first.

In general putting the:

	Inherits=default

in the: "index.theme" file is only going to cause trouble.  It should
not be necessary to do this -- the icon search code should add it.

>> 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.

I made both CrystalSVG *and* HiColor icons for the new icons.

>> 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.

That sounds like circular reasoning, and KDE does install icons in
HiColor -- check you installation (unfortunately, most of them are
CrystalSVG icons, but KDE does install them).

The issue is what *should* happen.

For example, you are using the Ikons icon theme and you place "Fit to
Page Width" on the toolbar in KPDF.  What icon *should* show up:

	The HiColor icon: "view_fit_window"
	The CrystalSVG icon: "view_fit_window"
	The icon: "unknown" in some theme

?  Which is better?  Which is what the spec requires?

And what should happen if you are running KPDF in GNOME?  Currently we
lack a standard for how to choose the icon theme so a KDE app being run
in GNOME will still use the KDE desktop's choice of icon theme but we
must presume that this issue will be fixed.  We must also presume that
icon naming standards will have been implemented.  When designing, you 
need to look to the future; when you fail to do so, you wind up with 
kludges that only work today.

-- 
JRT