James Richard Tyrer
tyrerj at acm.org
Sun Oct 16 17:26:11 BST 2005
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:
>> 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
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
>> The KDEClassic theme has:
>> 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:
>> 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
More information about the kde-core-devel