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

[Kenneth Wimer]

On Friday 02 June 2006 02:20, Waldo Bastian wrote:
> On Thursday 01 June 2006 18:32, Torsten Rahn wrote:
> > Am Freitag, 2. Juni 2006 01:14 schrieb Waldo Bastian:
> > > On Thursday 01 June 2006 12:15, Kenneth Wimer wrote:
> > > > On May 31, 2006, at 8:16 PM, James Richard Tyrer wrote:
> > > > please show me the part of the xdg spec that states this.
> > >
> > > "Implementations are required to look in the "hicolor" theme if an icon
> > > was not found in the current theme."
> >
> > And in a different place of the spec you'll find a reference to the theme
> > being talked about:
> >
> > http://www.freedesktop.org/software/icon-theme/releases/hicolor-icon-them
> >e- 0.5.tar.gz
> >
> > As you might notice this is a stub. So the spec only requires to have a
> > stub installed which makes sense if the respective desktop defaults to a
> > different theme already and wants to keep the shipped package lean.
>
> I'm not talking about the desktop, I'm talking about applications.

exactly! this is exactly what I have said....apps should install their "app" 
icon in hiclor so that other desktops can use our wonderfull icons.


it is really simple, yet the spec is confusing enough to cause all of this 
shit, as you say, for several reasons:

It starts off saying " In order to have a place for third party applications 
to install their icons there should always exist a theme called "hicolor" 
[1]. The data for the hicolor theme is available for download at: 
http://www.freedesktop.org/software/icon-theme/."

The first sentence seems ok. (yet the file mentioned is emtpy).

later in the same page it says "This name is chosen for backwards 
compatibility with the old KDE default theme" which is silly since we haven't 
used this for ages, but I can still live with that.

On the next page it goes on to say 

"These are the available contexts:

Actions. Icons representing actions which the user initiates, such as Save As.

Devices. Icons representing real world devices, such as printers and mice. 
It's not for file system nodes such as character or block devices.

FileSystems. Icons for objects which are represented as part of the file 
system. This is for example, the local network, “Home”, and “Desktop” 
folders.

MimeTypes. Icons representing MIME types."

So does this imply that all icons go into hicolor? I don't see it that way but 
the spec is very confusing here talking first about apples and then expanding 
to include all fruits.

Page 7 again clears things up..."So, you're an application author, and want to 
install application icons so that they work in the KDE and Gnome menus. 
Minimally you should install a 48x48 icon in the hicolor theme. This means 
installing a PNG file in $prefix/share/icons/hicolor/48x48/apps." 

First I would question why it only mentions Gnome and KDE...there are other 
desktops in this world.

Secondly, this seems to reflect the idea on the first page again, which we 
*do* agree with but the next paragraph simply does not belong in a spec as it 
adds artistsical value and human judgement thereof as well as a bit of 
bullshit.

"It is recommended that the icons installed in the hicolor theme look neutral, 
since it is a fallback theme that will be used in combination with some very 
different looking themes."

Please show me a work of art which has no style (as the spec says 
is "neutral"). The only thing that can come of this is that all linux artists 
agree on *one* style as there is no such thing as unstyled artwork.

I know that a certain group of people think that Tango is such a neutral theme 
but they are fooling themselves. Tango does have a style - I helped define it 
before it became so much like Gnome that I wanted nothing else to do with it.

Saying that all icons should look the same is simply crap and detracts from 
the value the artist creates when making a theme...indeed, it kills the idea 
of having a "theme" at all.

So the next sentence solves any problems with this poorly stated sentence by 
stating "But if you don't have any neutral icon, please install whatever icon 
you have in the hicolor theme so that all applications get at least some icon 
in all themes."

So what it comes down to is installing our app icons in hicolor. 

At this time, this would mean moving all crystal app icons into hicolor since 
that is our default theme. Adding whatever differently styled icons to 
complete the set of kde app icons is not understandable since it would ruin 
the look of kde itself and its apps running in other desktops.



>
> > > I'm really dumbfounded why this seems to be so difficult to understand
> > > by KDE artist ppl.
> >

no, you have simply misunderstood our position.

> > Perhaps because you didn't get the spec?
>
> Sure, I'm retarded. Now let's go back to the statement at hand, due to my
> limited mental capabilities I will explain things slowly, bear with me:
>
> [1] "we need HiColor icons so that if you select an icon theme which
> doesn't have the needed icon that the icon loader will fall back to
> HiColor."
>
> We established that the spec says:
>
> [2] "Implementations are required to look in the "hicolor" theme if an icon
> was not found in the current theme."
>

Only for the app icon itself, not everything else, or?

> So we can hopefully conclude from [2] that the part "if you select an icon
> theme which doesn't have the needed icon that the icon loader will fall
> back to HiColor." in [1] is no longer under discussion.
>
> As for the rest of [1], it seems to me that users of KDE applications would
> appreciate it that when they "select an icon theme which doesn't have the
> needed icon" that they get to see a proper icon instead of a question mark.
> Is that a statement you can agree with?
>

yepp. Just keep all the other bullshit out of this.

That is what my mail was about, nothing more, nothing less.

Have fun!
Ken