KColor is coming this Monday...
mw_triad at users.sourceforge.net
Fri May 25 21:45:30 BST 2007
Alex Merry wrote:
> On Friday 25 May 2007, Matthew Woehlke wrote:
>> Zack Rusin wrote:
>>> Now moving forward to the blend method. I think it's a neat
>>> addition. What I think is pretty silly is introducing another API
>>> and another implementation on top of what Qt already does and
>> I've been asking for months where to find blend() in Qt. No one has
>> told me, and I haven't found one. Therefore I fail to see how you can
>> say that Qt already provides this. In fact, since you subsequently
>> give an example of how to implement blend() anyway, rather than
>> referring me to an existing function in Qt, I can only assume that as
>> far as you know, there is no such function in Qt.
> I'm pretty sure that's not what Zack meant. He meant the duplication of
> a color-representation class, and possibly the lighten() and darken()
> methods. Hence the suggestion that there is a KGraphicsUtils namespace
> for blend().
Ok, but the reason for that duplication is the usual one, QColor is
deficient and KColor does things (that are still "color" things) that
QColor does not. Is that not the usual reason for KFoo vs. QFoo?
I agree that we should doc that KColor *IS NOT* meant to replace all
instances of QColor, only to be used where its features are needed.
"Still the prettiest." -- Legolas
(as quoted in The Very Secret Diaries by Cassandra Claire)
More information about the kde-core-devel