blend function urgently needed in kdelibs

[Matthew Woehlke]

Hans Meine wrote:
> I am not sure it is the right thing to hastily push a blend function into the 
> public API right now.  The problem could be that once you introduced the API, 
> you are forced to leave it the way it is, or make only BC changes.

While I appreciate the concern, a: I designed the API months ago, the 
"unfinished" is mostly translating design into compiling code, and b: 
blending functions are well-defined, as they have been around for ages 
:-). So I don't think an incomplete implementation of a well-defined 
function is reason for concern. (Also there is already a less-flexible 
form of the function in KDevelop 3.4, and darken()/lighten() have been 
in my own code for many months as well.) So while this may look like a 
rush job (and indeed, I admit that it /is/ in a sense), the only thing 
being "rushed" is the implementation; the basic design has been around 
for literally years, and many of the details have been around for 
months. The rest is a matter of taking the idea and making it compile.

In fact the only concern I have is that I dropped the 'flags' parameter 
(it effectively wasn't being used), but that can be added later as an 
overloaded function if it is needed.

> I agree that blending functionality is needed, and that there are enough use 
> cases, but my fear is that a "blend function" is not defined clear enough.  I 
> see that you have indeed provided some API and that you are working on it, 
> but that still looks quite unfinished (to me, no bashing intended).

The signature of blend() itself is now finished as far as I am 
concerned. There may be additional functions added to KColor, but 
blend() is what I am mainly pushing. IOW I expect to back off once the 
initial version goes in; it should still be polished for 4.0 but it 
doesn't need to be polished on May 28 :-).

If you have additional concerns, by all means, please share them, that's 
why I'm developing this openly.

> Your 
> recent posting on a KColor::darkContrast() looks sensible to me though - if 
> you can find such a high-level API that fits the needs of applications, that 
> would be ideal AFAICS.

blend() /is/ needed by some applications :-). Actually darkContrast may 
be a bit slower in coming because /it/ is totally new and hasn't had as 
much thought put into it yet. (Also see next comment.)

> So I propose to collect concrete existing code examples and try to find a 
> common scheme, like the need to "highlight" some text, while preserving 
> contrast with the background.

This is exactly what we need to do to make the /higher/ level functions, 
e.g. darkContrast(), which is why they will take longer and are not 
being pushed for the 28th. But they will be built on top of what is not 
in KColor. blend() is simply an implementation of generic blending, 
which as I say has been around for years (in OpenGL and paint programs, 
for example).

> Then I would prefer an API that allows you to 
> formulate just that, and does not require the application developer to care 
> about color spaces or the like.

Yes, this is the final objective. blend() is meant for fine-grained 
control when you /want/ to be able to work at such level of detail... or 
is meant to be called with default parameters :-). (Note that the major 
reason blend() supports color spaces is because the implementations of 
lighten() and darken() use HSY. Many users /won't/ care about the color 
space and will use the default Rgb.)

> Just my 2 and a half cents.

Thanks, they are good points you bring up. :-)

-- 
Matthew
"I can hear you / just barely hear you / I can just barely hear you"
   -- "I Can Hear You", by They Might Be Giants