--nextPart3249402.13mlPJTUjx
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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, =E2=80=9CHome=E2=80=9D, a=
nd =E2=80=9CDesktop=E2=80=9D
> 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=20
> but the spec is very confusing here talking first about apples and then
> expanding to include all fruits.

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

> Page 7 again clears things up..."So, you're an application author, and wa=
nt
> 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 oth=
er
> 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 wi=
th
> 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 artwor=
k.
>
> 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 fr=
om
> 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 whatev=
er
> 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. =
=46or=20
app and mimetype [1] icons (and emblem and device icons?) it's important=20
because the implementation that does the lookup may not be part of the=20
application self. For other icons (actions) it's slightly less urgent, sinc=
e=20
the implementation can be more liberal with the spec and use a fallback the=
me=20
that it knows to be included. Of course with the icon loader implemented in=
 =20
kdelibs I would be careful with any assumptions since you don't know what=20
kind of icon theme third party KDE applications ship along with their=20
application. You don't want to make applications written for older KDE=20
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 suppor=
t=20
the shared mimetype spec anyway but it will be an issue with KDE4.

Cheers,
Waldo
=2D-=20
Linux Client Architect - Channel Platform Solutions Group - Intel Corporati=
on

--nextPart3249402.13mlPJTUjx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBEf9mMN4pvrENfboIRArfuAJsE5oLKxs6VCBCICFxvshoHX9KIywCfcVvh
Lg3Hy5zzVIczqnersaJRz2M=
=bexH
-----END PGP SIGNATURE-----

--nextPart3249402.13mlPJTUjx--