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

List:       kde-core-devel
Subject:    Re: [Fwd: [kde-artists] Where to install (new) HiColor icons]
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2006-05-16 22:17:41
Message-ID: 446A4F85.10708 () acm ! org
[Download RAW message or body]

Oswald Buddenhagen wrote:
> 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
> 
Yes but ... (TM).  We should have the default as complete as possible, 
But we shouldn't install icons from other themes to make it complete.

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

Looks basically correct to me.

IIUC, from reading the code, each icon theme name is only added to the 
search list once, so loops are, thus, avoided.

KDE also has the issue that much of what would normally be called 
HiColor is installed as KDEClassic and even if you take the intersection 
of HiColor and KDEClassic, you will still be missing icons that exist in 
CrystalSVG.  So you also need to add on to the list.  You can either add 
before HiColor:

	... -> KDEClassic -> CrystalSVG -> HiColor

or (my preference) after HiColor:

	... -> HiColor -> KDEClassic -> CrystalSVG

You would only add these if they weren't already in the search list.

Also, IIUC from the link to what "larrosa" said, we really shouldn't add 
CrystalSVG explicitly but rather use the link: "default.<desktop name>". 
  Where 'desktop name' is KDE, GNOME, etc., pointing to the native 
desktop for the app.  I see a small issue here for apps that don't have 
a native desktop, but such apps should have HiColor icons.

-- 
JRT
[prev in list] [next in list] [prev in thread] [next in thread]