changing KGraphicsUtils?

[Michael Pyne]

On Thursday 31 May 2007, Thomas Zander wrote:
> What is wrong with having _several_ implementations using some blending of
> colors to figure out what the best behavior is?

i.e. have the other implementations sit out of kdelibs?  I'm not opposed to 
that (and indeed, that is currently the situation).

> I'm confused what the big haste is. Why do you guys want to settle this
> _now_?? (which I conclude from  you continuing this thread)

I no need for a huge push to get it into kdelibs, but I don't see a reason to 
hold it back just to see how overlayColors() turns out because I'm at least 
under the impression that we already have feedback that it is insufficient.  
This series of threads has been going on forever, I think it would be helpful 
if we can have people speak up at let us know *exactly* what they need with 
regards to color blending.

We have had a lot of people pipe up saying that colorspace foo is awesome, 
etc. etc. but I think we should focus on the problem of blending colors.  So 
who needs a blending function, and what did they need from it?  What I gather 
so far is:

* Usability improvements (blending would be the underlying code for lighten(), 
darken() and otherwise adjusting color schemes).
* Use in widget styles.  But perhaps this should be in KStyle then.
* And I've already forgotten what else.  But if you need this feature, don't 
just let implementors hash it out (the design-by-committee), you need to 
speak up too! :)

> We traditionally have 3 usages of some code before we find something
> eligible to import into KDELibs. For a reason.

I've thought that sometimes we had just 2.  And besides which, I believe we've 
already counted 3 (although Ion is not to my knowledge part of a KDE 
release).  But, this piece of code is small enough that it's not going to 
really trouble any application that needs it to simply implement it itself 
however.

> I'd really like to know why you guys are resisting the proposed action of
> letting the dust settle for a while now.

Well IMO all that's missing from blendColors() is adding the amount to blend 
in the method signature instead of requiring a separate setAlpha() call.  I 
consider the API broken with a manual setAlpha().  We can let the dust settle 
but then we're just post-poning the inevitable discussion to next week 
sometime. ;)

And as a final thought I think we should all just let this thread sit for 
tonight and try and think about what we're trying to accomplish here: making 
kdelibs better.  That includes adding code when it's useful, and perhaps more 
important, *not* adding code that doesn't provide a net positive.  We need to 
honestly evaluate whether this code is necessary for kdelibs (and conversely, 
if we're sure that this code won't be reimplemented five times over if left 
out).  There's been way too much anguish on this thread already so let's just 
get some time to start thinking more coolly before we fire up the email 
composer. :)

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070531/11ed0258/attachment.sig>