Common icon themes

[Antonio Larrosa Jiménez]

El Jueves, 14 de Noviembre de 2002 15:38, Alexander Larsson escribió:
> > 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!

Thanks, I'm still waiting the answer, but I hope I get it :)

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

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

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

Yes,

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

If those developers are silent now, then you can ignore what they said 
(maybe they changed their opinion).

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

It depends on how you implement it.

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

Well, perhaps I didn't say "thank you" yet, for all those compromises 
you've done (if not, I say it now: thank you). I understand that those are 
many compromises and that you've had to change some things in your code to
support hicolor and all that.

(*) I've been discussing with Dirk and Waldo on IRC about all the possible 
options since last Friday and finally we found a solution that I hope that 
you can accept, as it addresses all of the issues you had with my last 
proposal.

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

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

I've already implemented all of this proposal in KDE, and KDE 3.1 installs 
a default.kde symlink for you to use it. It's a big change that was 
introduced _very_ late into the freeze (just one day before the tagging), I 
hope you understand that we're also doing as much as we can to make shared 
icon themes a reality.

If you want to see the patch I commited, to check exactly what I 
changed, just tell me and I'll send it to you.

Greetings,

--
Antonio Larrosa Jimenez
KDE core developer - larrosa at kde.org
http://devel-home.kde.org/~larrosa/
Mejor leer algo en inglés que una adivinanza en español.