SLES10RC3 and Icon-lookup with KDE doesn't work as expected

[James Richard Tyrer]

Marcus Grassinger wrote:
> Hi Folks,
> 
> I'm evaluating whether KDE 3.5.1 (Level "a") respects the icon-lookup-spec.
> I concluded that it doesn't. Do you think that is due to SuSE-specific 
> changes in the kde-configuration?
> 
> The only time when icons get shown in KDE is when I place them in 
> /opt/kde3/share/icons/hicolor/[...]/apps/.
> The variable XDG_DATA_DIRS is set by default to 
> "/usr/local/share/:/usr/share/:/etc/opt/kde3/share/:/opt/kde3/share/:/opt/gnome/share/". 
> 
> 
> Do I understand the icon-lookup-spec correctly, assuming that kde should 
> at least look in "/usr/local/share/icons/hicolor" when I place an 
> "Icon=red"-entry in my *.desktop-file for example?
> 
> Has anybody a clue how I can get KDE on SLES10RC3 (still beta) to 
> respect the spec and look in at least the fallback 
> (/usr/share/icons/hicolor)?
> 
> Should I complain to SuSE, or isn't it worth the time and hassle?

The problem appears to be a bug in KDE so although it would be nice if 
you could convince some nice person at SuSE to fix it, it really isn't 
their fault.

The KDEClassic: "index.theme" had:

	Inherits=default

restored because it didn't fall back to HiColor.  A user contacted me by 
private e-mail and advised me that Gento substitutes:

	Inherits=hicolor

and that that didn't work either -- at least for him.

Remember, however, that the Icon Theme Spec allows other themes to be 
placed ahead of HiColor in the fall back lookup list.  I think that KDE 
does this and CrystalSVG is hard coded into the KIconLoader.

I disagree with this part of the Spec and vehemently disagree with hard 
coding it.  I think that additional fall back themes should come *after* 
HiColor.  IAC, it should be configurable in a file somewhere -- not hard 
coded.

-- 
JRT