[Fwd: [kde-artists] Where to install (new) HiColor icons]

[David Faure]

On Tuesday 16 May 2006 19:49, James Richard Tyrer wrote:
> That is what should happen if a generic (HiColor) icon isn't available.
>   However, Crystal Style clashes badly with many available themes.  If a
> generic icon is available, the fallback should be to that icon.

OK.

> I am making both CrystalSVG and HiColor icons for the new icons.
Ah! Great.

> Obviously, I installed the CrystalSVG icons as CrystalSVG.  The question
> is where to install the HiColor icons.
Right.

> The only exception is that it appears that I am the only one making the
> required generic HiColor icons.  All new icons should be made both in
> the current default icon theme and also in HiColor.
That makes sense I guess. Unless the crystalsvg one is not very crystally
and can be used for all ;)

> As the final backup, the icon loader should look in the current default
> (which should be referenced as "Default" rather than CrystalSVG so it
> will change if the default changes).  
Right - that's already the case for any theme that inherits from 'default'.

Am I right that hicolor is the ultimate fallback anyway? (as per the spec)

> My recommendation is that to meet 
> the specific situation in KDE that the Icon loader should search in:
> 
> 	1.  Chosen icon theme and its inherited themes
> 	2.  HiColor
> 	3.  KDEClassic (if the app's desktop is KDE)
> 	4.  Current Default for the app's desktop (CrystalSVG in KDE)
> 
> This will implement the intent of the spec to find a generic icon (if
> available) but use the current default as a final fallback so that some
> icon will be found if available.

I see, but this is merely a workaround for the fact that only crystalsvg has all
icons currently.
And I don't think kdeclassic belongs there, it's supposed to be "just another icon theme", isn't it?

I think both kdeclassic and crystalsvg should be made complete (otherwise
one can always inherit the other), and then other icon themes can
simply choose to inherit from kdeclassic or crystalsvg. And then the list
is back to 1/4/2 (where 2, hicolor, is merely for being able to use apps from
other environments).

You say that Antonio agrees with you, but he doesn't ;) He says that installing
everything to hicolor will cause for sure conflicts. The idea of hicolor is AFAICS
to install *application* icons (hi32-app-konqueror.png) so that they work in
other environments, but for the rest (like actions), there's no need to have them
there, the kde app can find them in the proper theme.

> This needs some discussion.  Not just the wording but other issues as 
> well.  This doesn't work for KDE since most of out HiColor icons are 
> installed as KDEClassic, and KDEClassic is missing many new icons.

Right. I think the current situation comes from the fact that most people
cared only for crystalsvg, so the rest is a bit of a mess.

> For the new icons, I am making *both* CrystalSVG and HiColor icons (as
> larrosa requested).  I installed the CrystalSVG icons as CrystalSVG and
> the HiColor as HiColor.
Great.

> The issue here is that JR seems to think that *new* HiColor icons should
> be installed as KDEClassic.  If that is done, these HiColor icons will
> not be available for fallback use for themes other than CrystalSVG.
(... or themes inheriting from crystalsvg).

Well, this is where there are still two solutions. 
We could leave hicolor alone except for application icons (so that other environments
can find them), and put action icons in kdeclassic; then other kde themes
can simply inherit kdeclassic if they want the classic look, or inherit crystalsvg
if they want the crystalsvg look.

> > Depends what your icon theme inherits from. Most themes inherit from
> >  CrystalSVG in order to get the kde-provided icons as fallback.
> 
> Why 
.. as fallback, obviously.

> they do this, if in fact they do 
Yes they do; I grepped kdeartwork/IconThemes/*/index.theme to say that.
They inherit "default" which is currently CrystalSVG
(plus one which inherits crystalsvg directly, and one which inherits hicolor just
to prove me wrong ;).

> is a mystery since with the 
> current bugs and design issues in the icon search algorithm CrystalSVG
> icons will be used anyway.
Maybe. I'm here to solve a dispute, not really to fix iconloader bugs ;)

> As I (and I think larrosa) said, the current Default (whatever is
> pointed to by the link: "default.kde" should be used as a fallback for
> KDE apps.  
Yes, but this is what gnome doesn't agree on.

> KDE does install icons in HiColor -- check you installation (unfortunately, most of them are
> CrystalSVG icons, but KDE does install them).
OK. Then I don't really understand Jonathan's svn reverts; we might have disagreements
on how to best do this, but if we already did install icons to hicolor then it's not such
a crime to add more icons to it...

> The issue is what *should* happen.
> 
> For example, you are using the Ikons icon theme and you place "Fit to
> Page Width" on the toolbar in KPDF.  What icon *should* show up:
> 
> 	The HiColor icon: "view_fit_window"
> 	The CrystalSVG icon: "view_fit_window"
> 	The icon: "unknown" in some theme

Currently the crystalsvg icon since ikons inherits "default".
If ikons wanted to have a more generic look it could inherit "kdeclassic" IMHO,
or hicolor if the icons are there indeed.

> ?  Which is better?  Which is what the spec requires?

Right now the spec would say that you get the crystalsvg icon due to
"inherit=default" obviously, no?

> And what should happen if you are running KPDF in GNOME?
Right now it doesn't make any difference since the icon theme selected
in kde is used by the icon loader, not the icon theme selected in gnome.

> Currently we 
> lack a standard for how to choose the icon theme so a KDE app being run
> in GNOME will still use the KDE desktop's choice of icon theme but we
> must presume that this issue will be fixed.  
Err... I think it's the opposite that is "missing": a way to use the current
desktop's current icon theme.

> We must also presume that 
> icon naming standards will have been implemented.  When designing, you 
> need to look to the future; when you fail to do so, you wind up with 
> kludges that only work today.
Yep. But we can't just assume someone else will do the work :-)

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