Common icon themes

Fri Nov 8 00:00:36 GMT 2002

El Miércoles, 6 de Noviembre de 2002 14:17, Alexander Larsson escribió:
> On Mon, 4 Nov 2002, Antonio Larrosa Jiménez wrote:
> > The only thing that I added was a boolean option "Hidden" which
> > specifies if an icon theme should be hidden to the user or not. In
> > case the icon theme is hidden, then it's not shown in the control
> > center and the user cannot select it. We've so turned hicolor to be
> > hidden from now on.
>
> Do you want this added to the spec?
>

Yes, that would be very nice, thanks.
Also, it would be nice if we can change that broken concept of "multiple 
inheritance" of icon themes so that it's not a " list of themes that this 
theme inherits from. If an icon name is not found in the current theme, 
these themes will be searched in the specified order. " as the current 
draft says, but just a _single_ theme (so instead of being a value of type 
"strings" it's just a "string"). Think of it, it really doesn't make sense 
and we've already removed the support for multiple inheritance in KDE 3.1 

> > > So, the desktop projects have their own default themes (e.g.
> > > "hicolor" for kde, "gnome" for gnome), which they install most icons
> > > to and that most other themes inherit from. But both still pick up
> > > icons from the "default" theme to allow.
> >
> > No, that's not (completely) correct for KDE anymore.
> > We have a default icon theme which is currently called crystalsvg
> > where we install all of our icons. The Inherit key in the icon themes
> > index.desktop file now just mention "default" instead of "hicolor" as
> > before. So, when reading that value, we interpret it as the default
> > icon theme (crystalsvg currently). That way all applications are able
> > to find all icons.
> >
> > Now you may wonder, where should applications install their icons to?
> > well, there is where hicolor come into scene. All 3rd party
> > applications install their icons to hicolor which is inherited by the
> > default icon theme (crystalsvg) and only by it. It would be ideal to
> > rename hicolor to default, but given that we want to keep backward
> > compatibility with existing KDE 3.0 based apps, we have to keep the
> > hicolor directory name.
>
> So, basically Gnome is hosed, and won't be able to show any icons for
> KDE apps? (since we don't resolve "default" to something else, and have
> a real "default" theme.)
>
> I'd like to work with you to resolve this in a way that can make sense
> for more than KDE.
>

Yes, we should work on this. Right now, I think that the current state of 
the icon loader in KDE makes more sense than the previous one, so I hope 
we can change the proposed standard and we can share this new behaviour.
Currently in KDE there's no "favoured" icon theme with respect to where do 
we install our icons. I mean, suppose that gnome wants to change the icon 
theme in the future to something different. will it change the icons it 
installs to the "default" icon theme? that would break the meaning of icon 
theme as a set of icons with a similar look because all the 3rd party 
applications which install their icons there now don't know if they're 
using an old gnome version (with old-style icons) or a new gnome version 
(with the new-fancy icons). With the latest changes in KDE, we keep a 
"hicolor" icon theme which is kind of "neutral" icon theme 
where 3rd party apps can install their icons without caring of the style 
or the icon theme the user is using. And also, they can install (optional) 
icons which match the style of some other icon themes to the specific icon 
theme directories.

I hope you see the benefits of this approach and can implement it for the 
next gnome release (without installing "gnome" icons there, as there's no 
"gnome" or "kde" icons anymore but only themed icons which should go into 
their own icon themes).

If you agree, the only problem that would be left is how to get the correct 
value for "default" in the "Inherit=default" line in the icon themes, as 
we have that hardcoded into kdelibs, so that we can change the icon theme 
easily.

Note if an icon theme has "Inherit=default", then it's interpreted as 
inheriting from the default icon theme as returned by 
KIconTheme::defaultThemeName() ("crystalsvg" in KDE 3.1), and only that 
theme can inherit directly from the "hicolor" icon theme (which is the 
neutral-style one). So for example, if the "Slick" icon theme has 
"Inherit=default", then the inheritance tree is :
slick -> crystalsvg -> hicolor

Brainstorming: The only solution I can think of right now is that we set a 
way to tell a desktop to look up icons also in other icon themes. So that 
if an application finds a environment variable 
"KDEICONTHEMES=gnome_default:default" then the previous inheritance tree 
would be converted to:
slick -> crystalsvg -> gnome_default -> default -> hicolor
Then the distribution could set that env. var. depending on the version 
installed.

Also, there would be a GNOMEICONTHEMES env. var. that, when set to 
"crystalsvg:hicolor" makes the gnome inheritance tree be like:
gnome_default -> crystalsvg -> hicolor -> default

Or perhaps those should be added at the end of the inheritance tree 
(probably makes more sense). Please tell me your opinion and ideas about 
it, I'm sure this is not the only solution and there are better ones.

I think the best would be that you also called your default (neutral-style) 
icon theme "hicolor", so at least we reduce the inheritance tree a bit 
(the larger it is, the slower the icon themes are, as they involve a lot 
of stat calls, so we want to keep at a minimum), and also you win backward 
compatibility with existing KDE apps which install their app icons to the 
hicolor icon theme. Also, it means you won't have to change the name of 
your existing default icon theme, but only add "hicolor" to the 
inheritance tree and ask developers of 3rd party gnome apps to install 
their icons there. In this case, our inheritance tree would be
crystalsvg -> default -> hicolor
and yours would be:
default -> crystalsvg -> hicolor

Hmmm, in that case, it doesn't make much sense to call that icon theme 
"default", because "default" doesn't mean anything related to the look of 
its icons (note the names of current icon themes always reference some 
peculiarity of its icons: hicolor, crystalsvg, technical, locolor, slick 
...). Do you think you may be able to change the name gnome uses for its 
"default" look ? or do you think we should change the default keyword in
"Inheritance=default" to something else (which doesn't clash with an 
existing icon theme name)? (like "Inheritance=_default_" for example).
Please, I would need a really fast answer here if you want to change what 
should be written in the "Inheritance=" line because there's only a couple 
of days to the release of KDE 3.1 .

> $KDEDIR/share/icons is gonna be /usr/share/icons on many distribuitions.
> That looks pretty neutral to me.

Thinking a bit more about it, yes you're right, there's not much of a 
problem about that. RH can always add
[Directories]
dir_icon=/usr/share/icons
to /etc/kderc and KDE will find gnome icons too even if $KDEDIR is 
something different. I suppose there are similar mechanisms to make gnome 
find kde icons (but making $KDEDIR=/usr is ok too)

> > Btw, I wrote a paper where I tried to explain the changes I did in the
> > last days to the icon themes. You may find it interesting, it's at:
> > http://devel-home.kde.org/~larrosa/iconthemes.html
> >
> > Btw, I'm afraid I don't know much of the current state of icon themes
> > in gnome 2, are they working in the stable release ? or will they work
> > in the next stable release? (in that case, at least you don't have to
> > keep backward compatibility yet).
>
> We have some code in the Gnome 2.0 code to read icon themes, and it sort
> of works, but it's not used much yet (although it works for e.g. the
> gnome menu if you set it up). For Gnome 2.2 (target january) we're gonna
> use icon themes a lot more.
>

I see.

> If we don't solve this now we're gonna end up with two incompatible icon
> theme formats that look almost identical and install in the same
> directories.

Yes. Any idea is welcomed.

Btw, sorry for taking so long to answer, between my studies and the 
soon-to-be-released KDE 3.1, I don't have much free time.

Greetings,

--
Antonio Larrosa Jimenez
KDE core developer - larrosa at kde.org
http://devel-home.kde.org/~larrosa/
Better read something in another language than a riddle in your own.