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

[Waldo Bastian]

On Thursday 01 June 2006 18:49, Kenneth Wimer wrote:
> 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-th
> > >em 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:

[Skip]

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

At the time it was written that was a valid reason.

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

It's something entirely unrelated.

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

First it talks about fruit in general and then it lists different places where 
you can store fruit. What is missing here is that "apps", "emblems" and 
"stock" are also used. There doesn't seem to be any functional aspect related 
to these contexts.

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

It seems to be an example.

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

I see.

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

Yes.

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

If you say so.

> > [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?

It doesn't make a distinction between different types of icons. That said. For 
app and mimetype [1] icons (and emblem and device icons?) it's important 
because the implementation that does the lookup may not be part of the 
application self. For other icons (actions) it's slightly less urgent, since 
the implementation can be more liberal with the spec and use a fallback theme 
that it knows to be included. Of course with the icon loader implemented in  
kdelibs I would be careful with any assumptions since you don't know what 
kind of icon theme third party KDE applications ship along with their 
application. You don't want to make applications written for older KDE 
versions unusable because a newer KDE version stops loading its icons.

[1] Mimetype icons haven't been an issue so far since KDE didn't yet support 
the shared mimetype spec anyway but it will be an issue with KDE4.

Cheers,
Waldo
-- 
Linux Client Architect - Channel Platform Solutions Group - Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060601/4906daac/attachment.sig>