James Richard Tyrer
tyrerj at acm.org
Wed Oct 19 03:52:07 BST 2005
Antonio Larrosa wrote:
> On Sunday 16 October 2005 18:26, James Richard Tyrer wrote:
>>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"?
> From the comments in the (KDE iconloader) code:
> Multiple inheritance is a broken concept on icon themes, so
> the next code doesn't support it on purpose because in fact, it was
> never supported at all.
I'm not certain exactly what that means.
The spec defines: "Inherits" as a list of "strings" so the spec requires
multiple inheritance, and recursive inheritance is required:
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).
I accept this as correct, but the rest of it has issues:
If no theme is specified implementations are required to add the
"hicolor" theme to the inheritance tree.
IIUC, the "hicolor" theme should always be added to the end of the
An implementation may optionally add other default themes in between the
last specified theme and the hicolor theme.
appears to be an issue. Adding other default themes doesn't look like a
IAC, it appears that "hicolor" should always be added to the end of the
icons search list: d->mThemesInTree. AFAICT, KDE does not do this. :-(
After further testing, I have come to the conclusion that Rodney is
correct and the KDE code is broken -- it works correctly in some cases
but does very strange things in other cases. IMHO (as an engineer) code
that acts that way was not correctly designed. It needs to be fixed
(probably first designed and then recoded).
So I have to totally disagree with Antonio, the problem is not the
concept, it is the execution that is broken in KDE.
I suggest that it is possible that recursion is not a good idea, but
that is the current standard. So, what the KDE code needs to do is
prepare a search list by recursion eliminating duplicates, but no
special treatment of "hicolor", as it appears the current code is
supposed to do. Then, "hicolor" and then the theme pointed to by the:
"default.kde" link should be added on to the end of this list unless
they are duplicates. Then some of the: "index.theme" files will need to
have "hicolor" or "default" removed.
I note that having a fall back for the fall back is possibly something
that should be addressed in the standard. There is a problem in KDE
where there is better support for CrystalSVG (as the current
default.kde) than there is for KDEClassic and almost nonexistent support
for HiColor. As a result, falling back to HiColor doesn't really work.
I think that we should fully support the HiColor theme, but I seem to
be out voted. So, when looking for an icon for a KDE app, falling back
to HiColor doesn't do much good. It would be better if there was an app
specific second fall back icon theme based on the desktop that the app
belonged to. This is mostly an issue for menu icons.
More information about the kde-core-devel