Common icon themes

[Alexander Larsson]

On Sat, 9 Nov 2002, Antonio Larrosa Jiménez wrote:

> El Viernes, 8 de Noviembre de 2002 17:11, Alexander Larsson escribió:
> 
> Hello Alexander,
> 
> I've been talking with Dirk Mueller at IRC (I was awake yesterday until 
> 4:20am discussing different ideas) and we found a much better proposal, so 
> I won't answer your questions about the previous proposal and just propose 
> you what I think is a much better approach. If in any case, you want me to 
> answer your questions, just tell me and I'll try to answer them so that 
> you understand better the whole idea behind icon themes.
> 
> The new proposal goes like this:
> 1) Add the "Hidden" key and remove multiple inheritance as before
> 2) KDE will install a kdedefault symlink in each release that points to the 
> default icon theme (crystalsvg for KDE3.1) and GNOME will install a 
> gnomedesktop symlink to its own default icon theme (gnome (*) or however 
> you call it). 
> 3) We keep hicolor as a default "neutral style" icon theme, where all 
> _3rd_party_ apps must install their "neutral style" icons. Note that when 
> I said 3rd party I don't only mean mozilla, acroread, or some other 
> desktop neutral app, but I mean apps which are not distributed from within 
> each desktop's CVS, but anyway, if you already read the "faq" I wrote, I'm 
> sure you already got the concept.
> 4) When an icon theme has an "Inherits=default" key, an empty "Inherits=" 
> key, or no Inherits key at all, it's interpreted as inheriting from the 
> desktop's default icon theme ( crystalsvg for KDE, gnome (*) for GNOME).
> 5) The default icon theme for the desktop (crystalsvg for KDE 3.1, gnome 
> (*) for GNOME) inherits from hicolor.
> 6) hicolor should inherit from the other desktop default icon theme (that 
> is, if we're under KDE, then hicolor inherits from the gnomedesktop 
> symlink, and if we're under GNOME, then hicolor inherits from the 
> kdedesktop symlink).
> 
> Of course those symlinks should be removed from the list of available 
> themes for the user (mainly because the icon themes are already available 
> as real dirs).
> 
> Under that scenary, if KDE changes the default icon theme again, GNOME will 
> continue finding KDE's icons because kdedefault will always point to the 
> right place.

This way of handling icon themes is very KDE and Gnome centric. It will 
never work with more than two users of the Icon theme specification, and 
requires magic code in the implementation to add the "other" desktop as 
inheritance in hicolor. It will not be acceptable for e.g. the ROX desktop 
project.

It will also leak all the non-application icons from kde into gnome and 
from gnome into kde (several KDE developers were agains the shared icon
namespace when I first proposed it) which can cause problems, and makes 
theme lookup slower and use more memory.

It also means that for every app that installs a neutral icon in hicolor 
and a crystalsvg icon too, gnome will get the hicolor one, which doesn't 
mix well with the rest of the crystalsvg icons.

Your definition of 3rd party apps is a bit strange too. Many apps are 
stored in the Gnome cvs tree that are not in any way part of the core 
gnome distribution. Why are these supposed to be treated differently?
 
In general it's not as important for Gnome to get the correct "current" 
default iconstyle for the KDE icons to show in Gnome (they won't fit in 
the selected Gnome style anyway). The important thing is to get *some* 
icon.

> Does this new proposal sound good?

I like the proposal I had incorporating the comments from Waldo better.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an uncontrollable hunchbacked stage actor on his last day in the job. 
She's a foxy belly-dancing college professor with an evil twin sister. They 
fight crime!