icon-theme-spec: Inherits=

[James Richard Tyrer]

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
search list

And this:
<<
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 
good idea.

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.

-- 
JRT