KColorScheme changes, take 3

[Matthew Woehlke]

Hans Meine wrote:
> Am Donnerstag, 06. September 2007 18:30:06 schrieb Matthew Woehlke:
>> Specific breakdown, with known will-be-users:
>> brush*1 ctor - KGamePopupItem
>> brush*2 ctor - add for symmetry/consistency, no (currently) known users
>> color*1 ctor - katepart
>> color*2 ctor - katepart, KGamePopupItem
>>
>> I *could* drop the QColor flavors, at the expense of forcing people to
>> use QBrush. Thoughts?
> 
> This sounds like a good idea.  Wouldn't it even work if a QColor is passed 
> (implicit constructor available)?

I thought I tried that, but... oh, that's interesting, 'class Foo : 
QBrush' doesn't inherit the implicit assignment (i.e. QBrush's 
operator=(QColor)). Which makes sense I guess.

Anyway, you're right, there's no reason for the QColor overrides, so 
I'll delete them. This means that both katepart and KGamePopupItem are 
making use of both new (compared to "v2") ctors, so there is no question 
about the library criteria (two users) being met. It also makes the API 
cleaner, which is good :-). I also updated the doc to make explicit 
mention that you can use QColor instead of QBrush, since people are 
likely to want to do that.

Thanks for the feedback!

Note: I realized KColorSchemePrivate isn't actually making use of 
applyStateEffects after all. On looking more closely, that will require 
some deeper changes to KCSP that I'd rather check in separately, so I'll 
do them later, i.e. after checking in what I have currently (they are 
SC+BC so can be done any time).

-- 
Matthew
When in doubt, give it a good swift kick.