What to do about KColor?
Boyd Stephen Smith Jr.
bss03 at volumehost.net
Sun May 27 10:23:40 BST 2007
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
> 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
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
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
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 =
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
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 `-'(. .)`-'
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel