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

[Oswald Buddenhagen]

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

> 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
   match crystal

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

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
this:
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
anywhere.
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.