Common icon themes

[Alexander Larsson]

On Thu, 14 Nov 2002, Antonio Larrosa Jiménez wrote:

> El Miércoles, 13 de Noviembre de 2002 13:05, Alexander Larsson escribió:
> > Whats the current status of this? I guess we need to decide what to do
> > before KDE 3.1 ships?
> 
> 
> Sorry but I'm very busy with "real life", I'm having the opportunity of 
> getting a job and so I cannot work on the icon loader as much as I'd like.

Congratulations to the new job!
 
> 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.

And you don't have to maintain two icon themes. If your app already have a 
neutral icon and a crystalsvg icon it installs the neutral one in hicolor 
and the other one in crystalsvg. But if you only have a crystalsvg icon 
you install that in hicolor (crystalsvg inherits from hicolor, so that 
effectively puts it in crystalsvg too).  

> Also, if you think it's not good to have kde/gnome desktop centry symlinks, 
> I can think on other solutions: 1) add also a roxdefault/other symlink or 
> 2) make the icon loader force _all_ symlinks in the icon themes directory, 
> so you can have the following 4 symlinks : kdedefault -> crystalsvg, 
> gnomedefault -> gnome, roxdefault -> iKons, whatever -> someicontheme, and 
> then all those icon themes are added at the end of the inheritance list 
> (supposing they weren't already in the inheritance list).
> 
> I hope you can agree with 2).

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.

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).

Requirement 1 is important for users of cross-desktop applications and 
third party developers.

Requirement 2 is important to app authors, as the unexpected existance or 
collision of icons can cause misbehaviour in applications. (It is also 
important to the KDE developers that objected when I presented my initial 
proposal for a shared icon namespace.) Furthermore it means less memory 
and performance is wasted on icons that will never be used by the running 
desktop.  

Your proposal breaks requirement 2, and is therefore unacceptable to me.

I don't think my requirements are unreasonable. In fact I think I've been 
very willing to compromise. I basically took whatever KDE was doing at the 
time, with minimal modifications, and made it into a standard document, 
I implemented support for it in Gnome, and I am even willing to change the 
name of the fallback theme to make it easier for KDE to get backwards 
compatibility for applications. I am not willing to break applications to 
get this accepted though.

So, it seems that we are unable to come to an agreement. I don't know what 
to do about this. I guess this means its up to users and distributions to 
fix this as best they can.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an unconventional crooked astronaut on his last day in the job. She's a 
chain-smoking mutant former first lady on her way to prison for a murder she 
didn't commit. They fight crime!