instantiating KGlobalSettings without KComponentData (was: A trivial patch to the shadow plugin for colorable shadows)

[Matthew Woehlke]

(I'm moving this to k-c-d since it's about KGS and we're no longer 
discussing kwin. Please drop kwin and '(was: ...)' when replying.)

Lubos Lunak wrote:
> On Thursday 03 of April 2008, Matthew Woehlke wrote:
>> Lubos Lunak wrote:
>>>  Code in kdelibs is (mostly) meant to be usable even without a
>>> KApplication instance. Looking at KGlobalSetting it refers only to qApp
>>> and even that is actually optional, so if KGlobalSettings doesn't work in
>>> the style, I'd consider that to be a bug.
>> Well... KGS makes extensive use of KGlobal, which cannot be used in
>> Qt-only applications. So, indeed, the style must avoid causing
>> instantiation of KGlobalSettings. (And, as I recall, styles must *also*
>> avoid nearly all calls to KGS, for that matter. There are a couple
>> exceptions; namely, those methods that have been extended to take an
>> optional KSharedConfigPtr so that KGlobal can be avoided.)
> 
>  From looking at the code, I don't see how using KGlobalSettings::self() and 
> connecting to its signal triggers any use of KGlobal, I haven't tried it for 
> real though. 

The signal itself (_k_slotNotifyChange) makes /extensive/ use of 
KGlobal. The ctor may not immediately or directly cause the problem, but 
once _k_slotNotifyChange is hooked up (which is done in the ctor), 
you've a disaster waiting to happen. So, KGS::self is off-limits to styles.

> I'd probably consider that to be a bug.

I don't. KGlobalSettings is almost unusable without KGlobal (i.e. a 
global KComponentData, which styles can't have), and I'm not at all 
convinced that it should be (for one, because it would require a massive 
re-work of the API to "fix").

-- 
Matthew
I sure hope they never make a hearse out of a Scion. I wouldn't want to 
be caught dead in one.