icon-theme-spec: Inherits=

[James Richard Tyrer]

Stephan Kulow wrote:
> Am Mittwoch, 19. Oktober 2005 04:52 schrieb James Richard Tyrer:
> 
>> I suggest that it is possible that recursion is not a good idea, 
>> but that is the current standard.
> 
> OK, then I suggest we change the "standard" to say that KDE does not 
> support multiple inheritance

I believe that you misunderstand what I said.  I said that it is
possible -- (that is) I am willing to listen to reasoned arguments about
it and I can see that there are points on both sides.  But, until such 
time as convincing arguments are made to change the standard (and the 
standard is changed), I (as I clearly stated) believe that KDE must 
properly support the standard.

So far, I have seen nothing definitive to indicate why the standard of 
using a recursive search should be changed other than the fact that it 
appears to be broken in KDE.  The answer to broken code is to fix it -- 
not to change the standard.

One argument against recursion is that a poor choice of "Inherits=" in 
one theme can screw up things.  Well, we should avoid that.

The specific problem which I have confirmed is that I have a new
(experimental) icon theme which has:

	Inherits=kdeclassic,hicolor,crystalsvg

KDEClassic has (was changed to):

	Inherits=hicolor

If I choose KDE Classic as my icon theme it works correctly.  However,
if I choose my new icon theme:

http://www.kde-look.org/content/show.php?content=27410

I get CrystalSVG style icons.  But, if I change KDEClassic to:

	Inherits=

then it works correctly.

This is not a broken concept, it is broken code.  If the code worked
according to my concept, it would work correctly.

I note that if my concept is used (either with or without recursion) 
that this should work.  If recursion is used, then all that USRHiColor 
would need is:

	Inherits=kdeclassic,crystalsvg

Perhaps the only good argument against recursion is that it is not 
needed.  But, we need to see cases to show which is better and my case 
is neutral.

-- 
JRT