icon-theme-spec: Inherits=

[Rodney Dawes]

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.

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

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

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

-- dobey