icon-theme-spec: Inherits=

[James Richard Tyrer]

Rodney Dawes wrote:
> On Sun, 2005-10-16 at 02:00 -0700, James Richard Tyrer wrote:
> 
>> The spec states:
>> 
>> The name of the theme that this theme inherits from. If an icon 
>> name is not found in the current theme, it is searched for in the
>> inherited theme (and recursively in all the inherited themes).
>> 
>> But exactly how should the inheritance tree be parsed?
> 
> 
> Let's say for example the "Foo" theme has Inherits=gnome,kdeclassic. 
> And, the kdeclassic theme has Inherits=default.
> 
> The way this *should* work, is that an icon is checked for in Foo, 
> gnome, kdeclassic, default, and then hicolor. If "default" does not 
> exist as a theme (it is NOT an internal alias for hicolor), then the 
> order would be Foo, gnome, kdeclassic, hicolor. I am pretty sure that
>  this is the behavior.
> 
But, my question is what happens if: "Inherits=kdeclassic,gnome".  Which
should be checked first: "default" or "gnome"?

> 
>> My experimental icon theme:
>> 
>> http://www.kde-look.org/content/show.php?content=27410
>> 
>> has:
>> 
>> Inherits=kdeclassic,hicolor_1,crystalsvg
>> 
>> where "hicolor_1" is a link:
>> 
>> hicolor_1 -> hicolor
>> 
>> to avoid another problem.
> 
> 
> You shouldn't need to create a symlink to hicolor, nor should you
> need to provide hicolor in the Inherits= list for your theme, as it
> must be the absolute last theme in the theme tree, according to the
> spec.

Yes, but ... (tm).  In this case, I need for it to search: "hicolor" and
then if no HiColor icon is available to then search "crystalsvg".  This
is necessary on KDE because we do not have HiColor for all icons.

> I /think/ there might be a bug with this in the KDE icon theme code.
> In trying to get Tango working across both current GNOME and KDE
> naming, several things have come up that lead me to believe there are
> a number of bugs in KDE's handling of icon themes with regards to the
> specification.
> 
> 
>> The KDEClassic theme has:
>> 
>> Inherits=default
>> 
>> and this does not work as expected so it is necessary to modify 
>> KDEClassic as stated on KDE-Look for it to work as expected.
> 
> 
> What is the expected behavior here? Do you have a theme installed 
> called "default"?
> 
On KDE, default: "default" is a link that currently points to:
"crystalsvg".
> 
>> Specifically, what I expect is that the icon loader will search:
>> 
>> 1.	usr_hicolor 
 >> 2.	kdeclassic
 >> 3.	hicolor_1 -> hicolor
 >> 4.	crystalsvg
>> 
>> And then see what "kdeclassic" inherits.
> 
> It should behave like dependencies in the packaging system. For
> example, when you have a program being packaged, libraries which are
> linked to by libraries that the program links to, become implicit
> dependencies of the program in question. Likewise, themes which are
> inherited from themes that your theme inherits from, become implicit
> inheritances of your theme. The structure is in fact a tree, and not
> a flat list, as you expect, because of this. When a theme gets
> parsed, all of it is parsed, including Inherits, before the next
> theme in the sibling list is parsed. It would be a bit of a hack to
> do otherwise, I think.
> 
Unfortunately, as I found out, when it works this way, there is no way 
for a theme to have explicit control of the order of inheritance.  The 
KDEClassic theme contains: "Inherits=default" and: "default" is a link 
to: "crystalsvg" so it searches: "crystalsvg" before it searches: 
"hicolor" which is clearly not what I want or need.

OTOH, it is possible that this is a KDE error in having KDEClassic 
inherit: "default" (which is currently a link to: "crystalsvg"). 
Perhaps that should be in the HiColor theme so that CrystalSVG is used 
if there is no HiColor icon for fall back.
> 
>> However, it does not work this way.  It appears that unless
>> KDEClassic is modified that #3 is crystalsvg and this is not the
>> expected behavior.
> 
> 
> I think that you mean unless you create the hicolor_1 -> hicolor, or
> in turn insert "hicolor" in your list before crystalsvg, that this is
> the case, or that you are expecting "default" to be an internal alias
> for "hicolor". 

No, on KDE, it ("default") is an explicit alias for "crystalsvg".

> The example in the specification mentions "default",
> however, the specification itself does not mention "default" being an
> alias to "hicolor" in any other section. I believe this is causing a
> bit of confusion, as it defines the base theme to be "hicolor", which
> in turn people seem to assume means that the "default" theme is
> "hicolor", which is false.

Yes, this is a source of confusion, but in this case: "default" points 
to "crystalsvg".

-- 
JRT