[Fwd: [kde-artists] Where to install (new) HiColor icons]
ossi at kde.org
Tue May 16 20:17:36 BST 2006
On Tue, May 16, 2006 at 10:38:13AM +0200, David Faure wrote:
> Let's have one theme that is complete, and that's CrystalSVG.
> Most themes inherit from CrystalSVG in order to get the kde-provided
> icons as fallback.
that's good for themes that are designed to be extensions of crystalsvg.
for everything else, it is pretty much fundamentally broken, as it is
bound to _certain versions_ of _kde_.
let's have some examples of how things *should* be.
1) kde default: crystalsvg -> hicolor
2) crystal extension: shinycrystal -> crystalsvg -> hicolor
3) kde classic: kdeclassic -> hicolor -> crystalsvg
the same situation applies to any 3rd party theme not designed to
as we can see, 1/2 and 3 have the exact opposite inheritance chain.
sounds like crystalsvg needs to inherit from hicolor and vice versa.
sounds weird at first, but i think it is perfectly valid. the icon
loader should simply abort when it gets into a loop, and then everything
now let's construct a really weird example: joe likes shinycrystal.
unfortunately, it is not complete. he also likes polishedcrystal
(another crystalsvg extension), which is also incomplete, but provides
some of the icons shinycrystal is missing. and so what joe really wants is
4) shinycrystal -> polishedcrystal -> crystalsvg -> hicolor
however, shiny* and polished* don't know about each other, so with
inheritance graphs provided by the themes themselves joe won't get
conclusion: the user should be able to select multiple themes. an
inheritance graph would be built *statically* from the available info
(selection order and inherits keys) and would be editable by hand.
any fundamental flaws in this reasoning?
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Chaos, panic, and disorder - my work here is done.
More information about the kde-core-devel