KColor is coming this Monday...

Matthew Woehlke mw_triad at users.sourceforge.net
Sat May 26 17:03:46 BST 2007

Simon Hausmann wrote:
> On Saturday 26 May 2007 09:54:38 Zack Rusin wrote:
> [...]
>> QColor KGraphicsUtils::blendColors(const QColor &one,
>>              const QColor &two,
>>             QPainter::CompositionMode mode =
>>                   QPainter::CompositionMode_SourceOver);
> IMHO that is a /much/ nicer API than
> KColor blend( const KColor& c1, const KColor& c2,
>                   double k = 0.5, double r = 0.5,
>                   BlendMode mode = BlendNormal,
>                   ColorSpec space = Rgb );
> Does kdevelop really /need/ to be able to specify k = 0.26452 and
> r = 0.7582394 in KDE 4.0.0?

r, maybe not in 4.0 (well, unless anyone wants BlendAdd in which case 
it's somewhat more important if not using defaults for both), but k yes; 
the alternative turns one line of code into at least three with the need 
to declare an additional temporary variable. And I'd rather plan for the 
future than write one implementation now and add others later (or worse, 
write one implementation in kdelibs only so I can *still* ignore and 
fork it for Ion). I put a good bit of thought into this over the months, 
and anything done to simplify it reduces its functionality and 
flexibility, and its ability to grow (in a BC manner) in the future.

Here is my perspective, as bluntly as I can put it. I am trying to 
/unify/ the use of color blending throughout KDE. I can do that with the 
current statics of KColor. With anything else, I can guarantee that I'm 
going to end up maintaining my own fork instead, which IMO defeats the 
purpose. There are many, many things I can do with KColor as it 
currently is, one of which is implementing the much talked about 
usability stuff, another of which is adding HSL support to KColorPicker. 
KColor is still IMO the easiest/best way to do both.

I still don't get why people seem so afraid of /optional/ parameters :-)

One suggestion that I would be amenable to is to move the statics into a 
namespace and keep KColor private (it would likely be used by other 
things in kdelibs, however).

One further note: I don't think using pigment is the right solution for 
basic UI work. I thought about it, and concluded that it brings to mind 
a certain proverb of Confucius about insects and old projectile weapons.

(sorry, .sig file is on the other computer)

More information about the kde-core-devel mailing list