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

[James Richard Tyrer]

Kenneth Wimer wrote:
> 
> On Jun 1, 2006, at 10:36 PM, James Richard Tyrer wrote:
> 
>> Kenneth Wimer wrote:
>>> On May 31, 2006, at 8:16 PM, James Richard Tyrer wrote:
>> 
>>>> Which is why we need HiColor icons so that if you select an 
>>>> icon theme which doesn't have the needed icon that the icon 
>>>> loader will fall back to HiColor.
>>> 
>>> please show me the part of the xdg spec that states this.
>> Actually, it would be the Icon Theme Spec:
>> 
>> Implementations are required to look in the "hicolor" theme if an 
>> icon was not found in the current theme.
>> 
>> 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"
>> 
> 
> I think that Oswalds mail to the xdg list explains the situation very
>  well.

Yes, and I support much of it.  Specifically, that KDE needs to have for
HiColor:

	Inherits=kdeclassic,crystalsvg

But, that that solution only works for KDE and we would need a general
XDG solution to the issue.  I do not (at first glance) think that his
"Succeeds" parameter is going to be the best solution.

>> Doesn't do much good to look there if there aren't any icons to 
>> find.
> 
> But it does even less

Is it preferable to display the "unknown" icon in the current theme to 
one that might not match perfectly?

> if the icons we install there are a mixup of 
> "neutral" yet ugly and differently looking styles.

"Neutral" is not an ugly style -- remember that I said that the term
'generic' is better.  If icons are truly generic, they should look OK
together.  The problem occurs if desktops start installing themed icons
as HiColor which the spec says should only be done if no other icons are
available.

If the issue which Oswald states is solved, then there would be no need
to install anything other than generic icons as HiColor.  Perhaps each
DeskTop could then have its own neutral/generic theme.

However, it should be noted that GNOME is currently installing HiColor 
icons (something which you are stating that KDE should not do).

> Many of the icons you want to install there are crystal icons

I am totally opposed to installing CrystalSVG icons as HiColor.  Did you
miss that somehow?  I advocate installing CrystalSVG icons as CrystalSVG
and generic icons as HiColor.

> that are so poorly drawn
> 
Which ones would those be?

> that they do not fit the real crystal style.

OTOH, if any artist doesn't like my CrystalSVG icons, they are welcome
to make 'better' ones.

> If KDE decides to use a theme as defualt, then that is were we should
>  stop. If the app icons need to go into hicolor so that other 
> desktops can use them, that is fine by me but letting this spec 
> determine the artistical values of our desktop  and apps is 
> non-sensical.
> 
>> It isn't going to look in KDEClassic for a fallback icon unless we
>>  have HiColor inherit KDEClassic.
>> 
>> <SNIP>
>>>> Doesn't this just beg the question.
>>> No, it refers to the spec.
>> The spec doesn't say that.  It refers to HiColor as a theme.
>> 
>> It is recommended that the icons installed in the hicolor theme 
>> look neutral, since it is a fallback theme
>> 
>> A place for third party icons is *a* use of the HiColor theme.
>> 
>> In order to have a place for third party applications to install 
>> their icons there should always exist a theme called "hicolor"
>> 
>> Be careful not to conclude that Socrates' cat is a dog.
> 
> Be careful not to read anything into a spec.

My point is that I think that you are doing so.

> If it is not there it is not implied.

If you do not understand my reference, All A is B does NOT imply that
all B is A, it only properly implies that SOME B is A.  To apply the 
proper rules of inference is not reading anything into anything, it is 
being careful not to do so.

> Installing other icons into this dir will create overlaps between 
> desktops, causing icons from one desktop to be replaced by icons 
> installed by another desktop later.
> 
This may be an issue if we have standard icon names -- if a user
installs multiple desktops with the same icon names.  However, this
doesn't mean that we shouldn't have any HiColor icons to be used as a
fall back.  If this become an issue, there is an obvious solution which
is desktop specific HiColor directories, e.g.

	hicolor.kde
	hicolor.gnome
	hicolor.xfce
	hicolor.<etc>

which is just like

	default.kde

This should work fine since it would always be the KDE icon loader that
needs to access the "hicolor.kde" directory, always the GNOME icon
loader that needs to access the "hicolor.gnome" directory, and etc..
This also solves the Inherits issue since the: "index.theme" file in
"hicolor.kde" could then contain:

	Inherits=hicolor,crystalsvg

or (better):

	Inherits=hicolor,default.kde

This desktop overlap problem is a more general issue which we already
have with the XDG menus.  It is something which XDG needs to address.
Using the DeskTop extensions to files might work as a general solution.

-- 
JRT