What to do about KColor?

[Boyd Stephen Smith Jr.]

Okay, I've been standing back and watching the threads as a user who is a 
programmer, but has not yet committed anything to KDE.  I've read most, if 
not all of the previous thread quietly, and I think I can add to things.  
I'm not a color or KDE expert by any means so feel free to ignore me.

On Saturday 26 May 2007, Thomas Zander <zander at kde.org> wrote about 'Re: 
What to do about KColor?':
> On Sunday 27 May 2007 01:35:54 Matthew Woehlke wrote:
> I find it admirable that you have such a long breath; well over 100
> messages have been written on 2 threads and a lot of them have stated to
> have some sort of issue with your proposal.

Matt is passionate about this, that much is clear.  Of course, lets not let 
passion get the in way of good code.

> Now you bring back the 
> original proposal, without any change that I can see!

Okay, I don't think you actually read this last email, but I could be 
wrong.

> Just the advice of the say is that you should really listen to the
> advice of many people that gave feedback in the other threads. This is
> not politics where trying again in the hope to get people to give up
> resisting.

He's refactored the code so that the KColor class is an implementation 
detail, instead of a publicly exposed API and also disclosed signatures 
for his lighten and darken.

He also provided an list of actual use cases.  It's fairly clear to me that 
we can take roughly a half dozen (or more) blend functions from outside 
kdeui and handle them through these methods -- that's a 83% reduction in 
code size ;) always a good thing.

> * The blend feature can be implemented to everyones (but yours)
> satisfaction using QColor.
> * KColor (and HSL) is not needed and not wanted for this blending.

I completely disagree. HSV (and hell even stupid RGB) blending/other 
operations can give good results sometimes, but just earlier this year I 
was going to do some KDE skinning and needed HSL/HSY color to get the 
right results.

Lighten and darken look better and give more usable (as in usability) 
blends when done in HSL rather than HSV.

> * Any non-RGB color space development in KDE should be focused on
> Pigment, having you work on KColor is duplicating work already done
> there.

Pigment and the usability stuff are important and he should coordinate his 
work as closely as possible with them to ensure that code is duplicated as 
little as possible.  That said, I, too would like some HSL

> * use a signature for blend() like this: 
> QColor KGraphicsUtils::blendColors(const QColor &one,
>              const QColor &two,
>             QPainter::CompositionMode mode =
>                   QPainter::CompositionMode_SourceOver);

Ugh, I know Matt covered this, but I do think it's an ugiler, less flexible 
API for what he's trying to achieve.  In the most average use case (50% 
blend) both calls look exactly the same 'cept this one requires a call to 
QColor#setAlpha first.

I would like to see the 'k' and 'r' parameters in Matt's signatures have 
more descriptive names.  Even if the letters 'k' and 'r' are used 
consistently in "the literature", I want KDE developers (including myself) 
to be able to use the function in interesting ways without reading a 
significant corpus of color theory and without Matt having to provide API 
docs that are a page and a half long -- descriptive parameter names can go 
a long way toward that goal.

> > (Anything less than that means Ion forks this stuff. Anything less
> > than the above version of blend() means Plastik doesn't use it and
> > retains the current private implementation. Either way, KColorPicker
> > and KPalette will most likely use the KColor methods these wrap.)
>
> Yeah, we all want to avoid forking, and I guess thats what you are
> aiming for here. You have to understand, though, that we value working
> on a basis of trust and consensus. And when consensus fails to build it
> tends to be best to call it a day.

Consensus is that we need a blend function in kdeui.
There is no consensus on whether this can be acceptably implemented in HSV 
or if we need HSL/HSY support.  (I'm on the side of HSL.)

I'm of the opinion that what we implement in kdeui should cover all the 
requests from the usability team.  I would *prefer* it support HSL/HSY.  
It makes sense that we should attempt to cover the use cases in themes 
shipped with KDE as well, which may want HSL/HSY blends.

> Just to close with something I found funny; your KColor-in-kdelibs is
> essentially also forking functionality that already exist in Pigment ;)

That's true, but it intended to be a temporary fork.  I think the blending 
is a fundamental enough operation that it sound be moved to kdeui (and 
have Pigment use that) instead of remaining outside.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03 at volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070527/814fac0d/attachment.sig>