kdenetwork/kit/icons

Antonio Larrosa Jiménez larrosa at kde.org
Mon Nov 4 13:25:34 GMT 2002


El Lunes, 4 de Noviembre de 2002 09:52, Alexander Larsson escribió:
> On 31 Oct 2002, Havoc Pennington wrote:
> > Hi,

Hi,

> > Antonio Larrosa Jiménez <larrosa at kde.org> writes:
> > > El Jueves, 31 de Octubre de 2002 17:49, Havoc Pennington escribió:
> > > > Antonio Larrosa Jiménez <larrosa at kde.org> writes:
> > > > > No, no. _Even_ if you're only supporting >=KDE3.1, apps outside
> > > > > of cvs _must_ install their icons to "hicolor". Remember that
> > > > > "hicolor" == "default", so what I mean is, applications must
> > > > > install their icons to the "default" icon theme. It's a bit
> > > > > unfortunate that we have to name the "default" icon theme
> > > > > "hicolor" (instead of plain "default"), but it's needed to keep
> > > > > backward compatibility with existing KDE apps.
> > > >
> > > > Remember that the icon theme spec is shared, so you don't really
> > > > want to call a theme plain "default" (it may not be the default in
> > > > GNOME or whatever). "KDE Default" would be a better name.
> > >
> > > Well, to quote the draft of the icon theme spec:
> > > (http://www.freedesktop.org/standards/icon-theme-spec/icon-theme-spe
> > >c.html)
> > >
> > > | In order to have a place for third party applications to install
> > > | their icons there should always exist a theme called "default"
> > >
> > > The problem is that if KDE changes to calling that theme "default"
> > > then we'll stop supporting old kde apps which people still use. With
> > > the recent changes I had to do to the KDE icon loader I tried to get
> > > something as similar to what was proposed in that page as possible.
> >
> > Can you write up what you had to do differently? We should document
> > that, or address it via spec changes.
> >

Sorry, I forgot to answer this question.
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.

> > > In any case, that "default" icon theme wouldn't be visible to the
> > > user (he cannot select it from the control center), so there's no
> > > problem in naming it that way (in fact, it's just the directory
> > > which is called "default" :) )

Sorry, I wasn't completely right there, it should read "it's just the 
directory which _should_be_ called "default" ". It's currently called 
hicolor.

> >
> > Ah, OK.
>
> So, my basic idea was this:
>
> We're not ever gonna have a common (e.g. both Gnome and KDE) default
> icon theme upstream, but even if we ignore that can-o-worms there must
> be a way for 3rd party apps (acrobat, netscape etc) to install icons
> that both desktops pick up. Thus the "default" theme that everyone falls
> back to last.

Yes,

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

> Of course, this set up sort of messes up Gnome getting the right KDE
> icons and vice versa, so maybe we want to install applications for

I suppose you mean "install icons for" :)

> KDE/Gnome apps that may be used on other desktop environments in the
> "default" theme too.
>
> Opinions on this?

Well, my biggest problem with getting common icon themes is that we need to 
use a "neutral" directory (currently KDE uses the 'kde-config --path icon' 
directory which is usually something like $KDEDIR/share/icons, etc.), so 
when we change to that neutral directory, we're going to loose the 
backward compatibility (we may use symlinks, but that will be a problem 
with current users with installed gnome and kde desktops)

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

Greetings,

--
Antonio Larrosa Jimenez
KDE core developer - larrosa at kde.org
http://devel-home.kde.org/~larrosa/
If I had only known, I would have been a locksmith. -- Albert Einstein




More information about the kde-core-devel mailing list