What to do about KColor?

[Matthew Woehlke]

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

I proposed three static methods in a namespace, plus some *private* 
implementation details. Unless I am mistaken that is a significant 
change. (In case it is cause for confusion, please note that the code in 
playground has /not/ been changed yet to reflect this.)

Let me try to explain this succinctly one more time... There are two 
suggestions currently on the table for a blend function in kdelibs:

Suggestion #1
-------------
QColor blend(QColor, QColor, QPainter::CompositionMode mode =
                              QPainter::CompositionMode_SourceOver);

= Advantages:
Uses an enum that exists in Qt.

= Disadvantages:
Incompatible with Pigment. We have no control over the implementation. 
At best we can write fast implementations of particular modes on an 
ad-hoc basis, but because we do not control the enum, we *must* rely on 
an extremely inefficient fallback implementation using a QImage (which, 
while I haven't checked, probably has to allocate on the heap). Calling 
the function requires three lines of code including declaration of a 
temporary variable.

Suggestion #2
-------------
QColor blend(QColor, QColor, double amount = 0.5,
              BlendMode mode = BlendNormal, ColorSpace space = Rgb);

= Advantages:
Easily called in the middle of code. Fully extensible in KDE, not 
reliant on TT. Conforms closely to KoColor, both making that a viable 
option for implementation and reducing the likelihood of adding similar 
methods in the future. Because KDE controls it, a (high performance) 
pure math implementation using only stack allocation is viable.

= Disadvantages:
Has more arguments. Doesn't use Qt.

-------------

As a result of the difficulty of use and performance concerns of #1, I 
cannot see that #1 provides enough benefit to justify converting 
existing homegrown implementations to this. Which means #1 fails to meet 
kdelibs inclusion criteria.

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