Common icon themes

[Alexander Larsson]

On Tue, 19 Nov 2002, Antonio Larrosa Jiménez wrote:

> El Jueves, 14 de Noviembre de 2002 15:38, Alexander Larsson escribió:
> > > About the proposals, I still think your proposal is not acceptable
> > > because on one hand, it breaks the icon theme concept (already
> > > explained) and also it puts double work on the artists and they (he)
> > > already told me they don't want to mantain two icon themes.
> >
> > It breaks the icon theme concept because you have to install crystalsvg
> > icons in hicolor? I don't think that is horrible price to pay, and in
> > fact I don't really agree that the concept is broken.
> >
> 
> (read the following paragraph only if you have good humour :) )
> 
> Think of it like this : You have men and women, and then you have toilets 
> for men and toilets for women. If you put men into the toilet of women so 
> that they can be found easier, then you break the concept of different 
> toilets for men and women ;-)

The analogy doesn't work, because the hicolor theme is hidden, so nobody 
will enter that toilet and by putting icons in hicolor they are also 
effectively in crystalsvg, so people entering the womens toilet will find 
women.
 
> > My hard requirements are:
> >
> > 1) For any icon name referenced in an application desktop file, Gnome
> > and KDE has to be able to get *some* icon, if one exists. It doesn't
> > matter exactly from what theme it is.
> >
> 
> This is fulfilled (I hope it's said that way).
> 
> > 2) In the namespace of icons that gets exposed to both KDE and Gnome
> > there are only application icons (and possibly later other kinds if we
> > manage to standardize more usages of icon themes).
> >
> 
> Ok, we (as icon loader developers) should take care of only loading apps 
> icons when following those symlinks (*).

I find this kind of change pretty ugly. I basically have to add a new 
function for app icon lookup, which is realy non-orthogonal and makes our 
APIs harder to understand. It also makes it harder for us to later share 
more parts of the icon namespace. (Since application code need to be 
changed.)

Magically handling symlinks also makes it harder for users to use symlinks 
to manage their own systems. (Granted, with your proposal they are only 
affected if the symlinks are named "default.*", which is better than 
previous proposals.)

> First, to make it not a "only kde/gnome solution", my proposal uses
> default.<desktopname> symlinks to each desktop default icon theme. I've 
> made KDE's icon loader follow all the default.* symlinks whenever an 
> application tries to load an icon that doesn't exist to be used in the 
> Desktop, Panel, or in general, in a .desktop file (that is, an apps icon). 
> So when this happens, the icon loader adds the icon themes pointed by 
> those symlinks to the list of icon themes.
> 
> For now, we're following those icon themes for all the icon types, as it's 
> too late to add so many changes to kdelibs. But I plan to make it only 
> follow apps icons in the themes pointed by the default.* symlinks before 
> KDE 3.2 (and gnome/rox/others should do that too).
> 
> Btw, the default.* symlinks were handled as icon themes, so they should be 
> removed from the list of icon themes shown to the user in the control 
> center (as those icon themes are already shown when using the real 
> directory name, instead of the symlink).

This is what I will do:

* Document the changes in the file format (add Hidden, remove multiple 
  inheritance).
* Say that when the inheritance chain ends (due to no Inherits line, or a 
  named theme that doesn't exist) implementations must insert "hicolor", 
  and are also free to add other themes.
* Change the references in the spec from the "default" theme to "hicolor", 
  and change the default theme tarball into a hicolor theme tarball 
  (icon-themes-base.tar.gz).
* Add a section to the standard about how application authors are 
  supposed to install icons (something in "hicolor" and optionally in 
  other named themes).
* Don't mention anything about symlinks in the spec.

This means any 3rd party app following this will work in both KDE and 
Gnome, without any special-casing. Gnome apps will also follow this, so 
they will just work from KDE. KDE apps not in CVS will apparently also 
follow this, according to previous discussion, so they will work from
Gnome.

Then I will add some KDE-specific application icon loader APIs to the 
Gnome icon loader, which follow the default.kde symlink. This API will 
only be used by the panel and Nautilus, and only when the normal icon 
lookup didn't work. This way, Gnome can read KDE CVS application icons.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a jaded hunchbacked photographer on the hunt for the last specimen of a 
great and near-mythical creature. She's a psychotic hypochondriac cab driver 
who inherited a spooky stately manor from her late maiden aunt. They fight 
crime!