What to do about KColor?

[Thomas Zander]

On Monday 28 May 2007 16:37:37 Ingo Klöcker wrote:
> > I expect people to adjust to the new concepts over the duration of
> > the KDE4 lifetime and when they do, then it becomes weird when there
> > are two conflicting ways to set the blending amount.
>
> Why conflicting? If I blend two colors with different alpha values a1
> and a2 then I'd expect to get the blended color with alpha value
> (a1+a2)/2 ( or (1-r) a1 + r a2 in the more general case ). Again,
> that's what I as email application developer (and maybe also as
> mathematician) would expect. I don't want to study color theory to
> understand what a certain method I want to use actually does. No, I
> want the method to do what I expect it to do. But I guess just as in
> application usability you'll get ten different expectations if you ask
> ten different people.

We are talking about slightly different things here :)

I agree with what you wrote above;  blending of 2 colors means take the 
average (and that is exactly what the current one does).

The request you wrote in the previous email is to change the blend method 
to include a double on how much blending is done.
So, instead of using the exact difference between the two you are able to 
state how strong the second color is applied to the first in returning 
the result.
And that makes sense in old colors, sure.  Where is starts to get a bit 
weird is if you have a color A and a color B where color B has an alpha 
of 50% and you call the blendColor with an additional 
parameter 'strength' that you also set to 50%.
The question that different people will probably answer differently is how 
strong the second color will have to be applied. Is it 50%? Or is it 25% 
(50% of the 50% that the color is already transparent). Or even something 
different based on color theory which is not perfectly linear...

So, that's why I stated its conflicting.

Hope that makes it clearer :)

> Whoever adds code to our core libraries should be aware of the fact
> that this functionality will be used by people who are not necessarily
> experts in the domain of this functionality. Functionality that does
> require more than a slight understanding of the matter and some common
> sense does IMO not belong into our core libraries but into some special
> purpose libraries, like say Pigment. So please keep the color related
> stuff in kdelibs dead simple and easily understandable for idiots like
> me. Thanks!

Fully agreed, and I was under the impression that this new method that was 
committed this morning does exactly that.
It blends 2 colors. Nothing more, nothing less.
-- 
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/20070528/74660c0c/attachment.sig>