blend function urgently needed in kdelibs
mw_triad at users.sourceforge.net
Wed May 23 16:33:31 BST 2007
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.
> 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,
> 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. :-)
"I can hear you / just barely hear you / I can just barely hear you"
-- "I Can Hear You", by They Might Be Giants
More information about the kde-core-devel