Common icon themes

[Antonio Larrosa Jiménez]

El Viernes, 8 de Noviembre de 2002 11:00, Alexander Larsson escribió:
> On Fri, 8 Nov 2002, Antonio Larrosa Jiménez wrote:
> > snipped lots of comments
>
> Ok. What about this proposal:
>
> ------------------ Proposal -------------------
>
> We create a package called something like icon-themes-base.tar.gz that
> doesn't depend on anything. It installs (and when packaged, owns)
> $prefix/share/icons/hicolor with the corresponding index.theme and
> subdirs. (This is needed so there won't be any contention about who
> installs these files, and e.g. gnome won't depend on kdelibs to install
> it for them.)

Ok, this icon-themes-base would be a common external dependency.

>
> Then we add the Hidden attribute to the spec, and set that on the
> hicolor theme. We also remove the support for multiple inheritance from
> the spec
>

Ok.

> 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.
1.2)If those icons are the same... well, it's illogical to keep duplicated 
icons in hicolor and crystalsvg.

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.

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.

> Then we make the Inherits field optional (it actually already is), and
> if it is missing in a theme, then the theme implementation is free to
> pick the final inheritance structure, but it *must* include at least the
> hicolor theme. So, kde would pick "crystalsvg, hicolor" and gnome would
> pick "gnome, hicolor".

Ok.

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

Greetings,

--
Antonio Larrosa Jimenez
KDE core developer - larrosa at kde.org
http://devel-home.kde.org/~larrosa/
The only thing that interferes with my learning is my education.