[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [Fwd: [kde-artists] Where to install (new) HiColor icons]
From:       David Faure <faure () kde ! org>
Date:       2006-05-16 8:38:13
Message-ID: 200605161038.13497.faure () kde ! org
[Download RAW message or body]

On Monday 15 May 2006 18:43, James Richard Tyrer wrote:
> I am not talking about making "new kdeclassic icon", I am talking about
> making NEW icons.  Icon such as:
> 	tab_remove_other.png [...]
> which didn't exist before I made them.  And, I am not making KDEClassic
> icons for these *new* icons, I am making generic HiColor icons.

OK, now I understand the issue better.

> Not sure what you mean.  I use my icon them on my system (USR_HiColor)
> and if an icon is missing I want fall back to HiColor,KDEClassic if
> they exist.  I do NOT want CrystalSVG to show up as the fall back unless
> it is the only icon available.

Exactly. And this fallback to CrystalSVG surely happens many times already, \
 that the only icon available is the one from CrystalSVG, doesn't it?

> I am not going to make icons for every icon theme that exists to avoid
> installing new generic icons in HiColor so that they can be used as a
> fall back.

But it would work the same if installing those new icons in CrystalSVG.
Let's have one theme that is complete, and that's CrystalSVG.

I understand that from an artist point of view it might be a bit weird, if \
the icon doesn't have the "crystal" look at all - but I think this is \
already the case for many icons in that theme. It is the default icon theme \
in KDE, the one which KDE apps install icons into. I don't see a reason to \
make an exception for a few icons.

In all practical terms, aren't we just arguing over naming, without any \
runtime difference? I mean most icon themes have to inherit CrystalSVG \
anyway because they can't provide 100% of the icons, right? So let's remain \
consistent: KDE applications provide CrystalSVG icons, and icon themes can \
override that.

> > don't clutter up the hicolour namespace.
> 
> I am (or was) using the HiColor "name space" (icon theme) as the spec
> states it is to be used, as a fall back icon theme (yes the spec says
> "icon theme").  For it to be used as a fall back icon theme, it needs to
> have icons in it.

But not necessarily all the icons. Yes hicolor *can* (according to the \
spec) be used as a fall back icon theme, and this mechanism is used for 3rd \
party apps. But this isn't the way we use it in KDE, and I think this is \
where the heart of the misunderstanding comes from. As Thiago pointed out \
to me: KDE never uses "hicolor" directly. We ALWAYS have a theme and that \
theme is NEVER "hicolor".

Please read https://www.redhat.com/archives/xdg-list/2002-November/msg00073.html
 by Antonio Larrosa. "KDE should install an icontheme [...], the hicolor \
icon theme is there for app developers who don't belong to a specific \
desktop. So hicolor should be desktop-neutral, look-neutral, \
vendor-neutral." There was some disagreement from the gnome side (mostly \
about the "symlink to the default theme" idea), but really, this isn't the \
discussion I want to get into again. What we (well, Antonio ;) implemented \
in KDE is exactly what the post above describes: the KDE desktop (i.e. apps \
in kde svn) install its icons to crystalsvg.

This argument is about "doing something correct per the spec, but unlike \
what KDE did up to now" versus "doing things like KDE did up to now, which \
is also correct per the spec". I strongly encourage that you do the latter \
for now.

If you want to change the way things work then we should start by reviving \
that xdg-list discussion and coming to a complete agreement about how \
things should work, and then we might change the iconloader, etc. We're not \
at that point, so for now: please let KDE SVN app install their icons to \
crystalsvg.

> You appear to have ignored my point which is that if you are using an
> icon theme other than CrystalSVG or KDEClassic and you need the icon
> (for example): "view_fit_width" what should happen?  Should you get the:
> "unknown" icon, or should you get the HiColor icon? 
Depends what your icon theme inherits from. Most themes inherit from \
CrystalSVG in order to get the kde-provided icons as fallback. Otherwise \
they would be broken since they would lack many icons, wouldn't they?
Even kdeclassic inherits crystalsvg.

> Isn't that what the fall back theme is supposed to be used for: fall \
> back?  
hicolor is the "default cross-desktop fallback", so that desktop-neutral \
apps work in all desktops. Konqueror is part of KDE, it should provide \
icons for the KDE-default icon theme by default.

> If the generic hicolor icon is installed in KDEClassic and HiColor \
> doesn't inherit  KDEClassic, then what happens -- what should happen?
The question doesn't make sense in KDE since we don't install icons to \
hicolor.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


[prev in list] [next in list] [prev in thread] [next in thread]