What to do about KColor?

[Thomas Zander]

On Sunday 27 May 2007 01:35:54 Matthew Woehlke wrote:
> Since the underlying question got totally derailed, let's start over.

Matthew,
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. Now you bring back the 
original proposal, without any change that I can see!
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.

To keep it clear, I'll give a really short answer to what I read in those 
answers from respected KDE people. (argumentation in the other thread).

* The blend feature is good to have.
* 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.
* Any non-RGB color space development in KDE should be focused on Pigment, 
having you work on KColor is duplicating work already done there.
* use a signature for blend() like this:
QColor KGraphicsUtils::blendColors(const QColor &one,
             const QColor &two,
            QPainter::CompositionMode mode =    
                  QPainter::CompositionMode_SourceOver);

> (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.

Just to close with something I found funny; your KColor-in-kdelibs is 
essentially also forking functionality that already exist in Pigment ;)
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070527/ae3cd6e6/attachment.sig>