[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: kdegraphics/kpdf/kpdf
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-11-17 20:31:23
Message-ID: 200411172031.23221.frans.englich () telia ! com
[Download RAW message or body]

On Wednesday 17 November 2004 19:44, Albert Astals Cid wrote:
> If i understood that page correctly that means i do not need hi-color on
> cvs? On that i should move hi-color to kdeartword?
>
> Could you please clarify?

I'm also curious in this matter. This is how I see it(please deny/confirm):

If an application has only one icon, be it in crystalsvg "look&feel" or 
anything else, it should be installed into hicolor. This is because hicolor 
is the default theme which /all/ themes inherits, and the icon will hence be 
available in all themes, regardless of which one is used(crystalsvg, 
gnome-icon-theme, or anything else).

If an application has two or more icons, it should install one icon into 
hicolor, and the other icon(s) into their respective theme folders. It's here 
I'm a bit unsure; if an application has a "default" icon plus a crystalsvg 
icon, shouldn't the crystalsvg icon be _in_ the theme, 
kdelibs/pics/crystalsvg? It seems more modularized and flexible to me.

What it boils down to(AFAICT) is that KDE does not play very well with the 
fd.o icon theme spec; most applications only have one icon but they 
nevertheless install into crystalsvg, meaning that they don't work with other 
themes. In other words, most icons(not those in kdelibs/pics/crystalsvg) 
needs to be renamed from cr-* to hi-*.

This probably sounds confusing; "Should an icon with crystalsvg look not be 
installed in crystalsvg?" Explanation: the icon will still appear when the 
crystalsvg theme is used(KDE's default setup) since crystalsvg inherits 
hicolor, the difference is that the icon will also show up with other themes, 
and that's better than nothing.

Doesn't that mean hicolor becomes a mixture of all different kinds of icons? 
Yes, and that's a feature not a bug, because hicolor is not a /theme/, it 
doesn't have a look&feel, but is a default namespace which all different 
kinds of applications, 3rd parties, and so forth, installs into, such that 
their icons is available everywhere. You can't choose to "use" hicolor as 
your theme.

However, KDE /did/ have a theme(as in theme) named "hicolor" which had a 
particular look, and when the XDG spec was written, "hicolor" was chosen as
name for the default theme/namespace to provide backwards compatibility with 
KDE.

A+? D-? Should I crawl back under my rock?


Cheers,

		Frans

	
[prev in list] [next in list] [prev in thread] [next in thread]