blendColor that doesn't need additional setup code

[Matthew Woehlke]

Thomas Zander wrote:
> On Tuesday 29 May 2007 02:28:09 Aaron J. Seigo wrote:
>> does that make sense? =)
> 
> Well, it confirms quite well what I said a couple of days ago;
> Ingo, you and Andreas all have different solutions for what to do with the 
> alpha channel.
> Ingo even had an if/then solution in there to make the blending behave 
> conceptually different depending on wheather there is an alpha channel 
> set at all.

Clearly this doesn't sound like a good idea, the result should always be 
predictable :-).

> Now, I don't mean to be rude and I don't mean to cut off well meant 
> energy, but I really like to have people wait this one out for, say, a 
> month to get our bearings and get various real life examples written.

In a month there won't be enough time left to build meaningful code 
(i.e. "the usability stuff") on top of this. That's one reason I was 
pushing so hard.

> With real use cases and code we can then look at those and quite probably 
> we can come up with a concept of "what should it do" that are a bit more 
> aligned then our opinions are now.

What do you consider Plastik to be? Or Ion, or KDevelop?

> And lacking any colors experts that are great at designing APIs at the 
> same time, lets first figure out a diverse enough set of usecases before 
> we do so, to make an informed decision.

Do you measure "expertise" in scholastic degrees, or working experience? 
I'm also an artist (not a great one, I admit :-)) that has been working 
with computer graphics for years. I'd like to think I have some of the 
latter (and I've had a bit of formal art training as well).

I still like this signature:
blendColors(QColor, QColor, qreal)

...and treat the alpha as 'just another channel'. Anyone that has used 
gradients expects this, others have already mentioned that they expect 
this, and because AFAIK we currently have no use case for the blend 
mode, we can omit it and use about five lines of math to do the 
operation lightning fast (and with no heap allocations). And then 
kdelibs/kstyles/plastik/misc.cpp goes away with only minor changes to 
plastik.cpp (s/alphaBlendColors/KGraphicsUtils::blendColors/ and change 
the third arg from an int to an appropriate real), and we have our first 
real user.

I'm also fine with adding overlayColors as well if people want that (in 
fact, my original proposal included both). In fact, here is a dumb idea, 
what if we add both and wait to see which gets used more? Then in a 
month we can look at removing one or the other (or neither).

-- 
Matthew
"A mouse is a device used to point at the xterm you want to type in."
   --Kim Alm, A.S.R.