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

[James Richard Tyrer]

Jonathan Riddell wrote:
> On Sun, May 14, 2006 at 12:05:38PM -0700, James Richard Tyrer wrote:
>> The clear message is: "NO HELP WANTED".  If there is no useful 
>> discussion, that is the way I am going to take this and simply stop
>>  making icons.
> 
> If you want to help make new kdeclassic icons put them in kdeclassic.
> 
> 
> 
> 
I am not talking about making "new kdeclassic icon", I am talking about
making NEW icons.  Icon such as:

	tab_remove_other.png
	view_fit_height.png
	view_fit_width.png
	view_fit_window.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.


>> The icon theme support remains a mess which I am willing to help 
>> straighten out.  The attitude appears to be that nobody cares if 
>> icon themes don't work correctly since there is no problem as long
>>  as you use the Default (CrystalSVG).  If that is the case, why not
>>  simply delete all other icon themes since they don't work 
>> correctly.  I have a major kludge installed on my system as a work
>>  around in order to get HiColor/KDEClassic to work correctly.
> 
> You are mixing hicolour and kdeclassic again.

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.

> Icon themes work fine,

I presume that you mean except for *the* bug which means that they don't
work correctly.  If you use a theme other than CrystalSVG, you get
CrystalSVG icons if the needed *size* of the icon is missing.  This is a
serious bug and a violation of the spec.  Denial does not make bugs go
away. :-)

> if there are missing icons in a theme such as kdeclassic feel free to
>  fill them in.

My concern is not filling in the missing icons in KDEClassic.  I am
willing to do that.  My concern is what happens with *new* icons that
are missing in other icon themes.  This is why we have a fall back icon
theme.

>> Basically, what JR has said is the KDE will NOT support the HiColor
>>  icon theme.
> 
> I never said that, i said we won't ship icons in hicolour because 
> that is incorect (hicolour being for third party apps).

Then why does GNOME support HiColor and ship a HiColor theme.
Supporting HiColor means having a HiColor theme -- shipping a HiColor
theme like GNOME does.

>> Was it up to him to make that decision?  Yes, there are some issues
>>  that need to be considered, but GNOME supports HiColor and 
>> FreeDesktop.org standards require it.
> 
> Our support for hicolour is exactly the same as Gnome's support for 
> it.

Have you used GNOME lately?  If so, you would know that what you say is
not correct.

> We both ship with hidden=true in the file

This question is not about that.

> so you can not select hicolour as your theme

Very strange!  On my GNOME installation, I *can* select HiColor as the
icon theme.  Apparently, GNOME simply ignores the "Hidden=true" in the
"index.theme" file.

> because it is not an icon theme but is a fallback namespace for use 
> by third party applications.

It is there where you are wrong.  The spec refers to HiColor as a theme,
but that isn't the question.  If HiColor is only a fall back icon theme,
then it needs to be used as such.  It needs to be supported and it needs
to have generic icons in it.

> You can find the definitive index.theme file for hicolour in 
> freedesktop.org's CVS, and you'll find it also has Hidden=true in it.
> 
> 
We are not discussing that issue here.  I accepted Frans Englich's
suggestion on that (having a wrapper theme for using HiColor) except
that it doesn't work because of *the* bug in the KDE icon search code.

I have issues with the spec, but there is no point in discussing them first.

>> I have made new icons for KDE Standard Actions and Konqueror 
>> functions. We need to have HiColor icons for these since KDEArtWork
>>  installs several icons themes that don't have them.  And there are
>>  many other icon themes available on KDE-Look that don't have them
>>  yet.  Not having them violates the intent of the spec and causes 
>> problems for anyone that doesn't use CrystalSVG.
> 
> Then fill in the gaps in those themes,

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.

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

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?  Isn't that what the
fall back theme is supposed to be used for: fall back?  If the generic 
HiColor icon is installed in KDEClassic and HiColor doesn't inherit 
KDEClassic, then what happens -- what should happen?

Also note that there are two possible solutions here.  If HiColor
inherits KDEClassic, then in many cases the new icons could be installed
as KDEClassic although I really don't see what is accomplished by
installing the new generic icons as KDEClassic rather than HiColor.  If
KDEClassic is a dead and unmaintained theme, then the only changes made
to it should be to add missing sizes.

-- 
JRT