Common icon themes

[Alexander Larsson]

On Fri, 8 Nov 2002, Antonio Larrosa Jiménez wrote:

> El Viernes, 8 de Noviembre de 2002 11:00, Alexander Larsson escribió:
> > Then we make the rule for application icons (those referenced by the
> > desktop file spec):
> > You *must* install an icon in the "hicolor" theme. It can be of any
> > sort, but preferably a "neutral" look. Additionally they may install
> > icons in any themed directories it want.
> >
> 
> I'm not sure of this. Does it mean that kde (and gnome) will have to 
> install their apps icons (let's say konqueror.png or nautilus.png) to 
> hicolor (so that the other desktop finds it) and to crystalsvg/gnome (to 
> use the default icon theme of each desktop) ?
> 
> 1.1) On one hand, if those icons are different, I don't think it makes 
> sense to mantain two icon themes in kde's cvs nor in gnome's cvs.

Why not?

> 1.2)If those icons are the same... well, it's illogical to keep duplicated 
> icons in hicolor and crystalsvg.

It's not that bad.

> So we have to install app icons only to one place:
> 
> 2.1) If we install them to hicolor, then we're breaking the whole idea of 
> icon themes (as most of the crystalsvg's apps icons would be inside 
> hicolor instead of where they should be in the crystalsvg directory, and 
> evenmore, action/mime/devices icons would still be in the crystalsvg 
> directory). That would be a real mess. Think also about kde installing 
> crystalsvg icons for mozilla into hicolor and gnome installing its own 
> mozilla icons (with the gnome look) into hicolor. Doesn't make sense 
> neither.

KDE should not install the mozilla icon to hicolor. Mozilla itself should. 
KDE can install it to crystalsvg of course.

> 2.2) That means we should install them to crystalsvg. But then we're back 
> to the problem that (e.g.) konqueror.png would only be in crystalsvg and 
> so when gnome's panel finds konqueror.desktop it won't find konqueror.png 
> because crystalsvg is not in gnome's icon theme list.
> 
> Perhaps (rewriting my previous idea), we should use a FORCEICONTHEMES
> env. var. that forces each desktop to append those icon themes at the end 
> of the icon theme list. That way, it can contain 
> FORCEICONTHEMES=crystalsvg:gnome
> and each desktop could remove icon themes which are duplicated in their 
> respective icon theme list.
> Of course, each distribution could set that env. var. accordingly to the 
> installed packages. Or maybe we should use a config file to store those 
> things.
> 
> In any case, I think 2.2 is the way to go.

This is a non-solution for several reasons:

a) It won't work for novice users that just want to use gnome apps from 
kde or kde apps from gnome. They have to set up some strange environment 
variable to make it work. Lots of people won't do this, but just complain 
that it's "broken". If a distribution is forced to always set it then 
we're just wasting env-var space in every process for something we should 
just handle automagically.

b) People on the xdg-list violently opposed to sharing the namespace 
between the desktops. And this is exactly what this will cause. Gnome will 
get the mimetype/action/etc icons from KDE, and KDE will get the 
mimetype/emblems/etc from Gnome. Chances are high that the names collide 
and you get an icon you didn't expect. It also means that icon lookup will 
be slower and use more memory because each desktop needs to read in all 
the (non-application) icons that you normally don't use from the other 
desktop. 

c) You've been saying all the time on your webpage and here that apps are 
supposed to install icons to hicolor, now you suddenly say they should 
install in crystalsvg? Aren't we back to step 1 then? (I.E. what if KDE 
wants to change the default theme again?)

> > and with an external package owning the hicolor theme so that it can be
> > shared.
> 
> Ok, then I'll commit in the following days an icon-themes-base cvs module 
> to kde's cvs where we can keep hicolor's out of kdelibs and any other 
> dependency. Is that ok?

Maybe we should put it in cvs on freedesktop.org, and the tarball next 
to the spec. In fact, I already have a tarball of the default theme there. 
I think all you need to do is s/default/hicolor/ and we'll be all set. In  
practice the package won't ever change, so it won't be a pain to 
coordinate.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an obese Republican vagrant searching for his wife's true killer. She's a 
pregnant mute doctor fleeing from a Satanic cult. They fight crime!