[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: changing KGraphicsUtils?
From:       Hans Meine <hans_meine () gmx ! net>
Date:       2007-05-31 11:54:35
Message-ID: 200705311354.35910.hans_meine () gmx ! net
[Download RAW message or body]

Hi Thomas!

Am Donnerstag, 31. Mai 2007 13:27:11 schrieb Thomas Zander:
> Does it make sense to have 2 methods to not upset some people? Its not a
> great idea for an API that has to be public for the next years.

I am too concerned about defining an API without looking at application use 
cases.  However, your following comment looks like a misunderstanding:

Am Donnerstag, 31. Mai 2007 09:30:39 schrieb Thomas Zander:
> * we now have two similar methods that people have to choose from. We
> explicitly made the blendColors to be good enough for everyone to use by
> making it a very simple API and good enough implementation.
> Adding a second next to that counters this result gained and therefor
> should be avoided.

Please note that mix[Colors]() defines a linear interpolation of the RGBA 
vectors, which is needed for gradients (clear use case, and indeed I wrote 
code that needed that, but they're not part of KDE) but is *not* one of the 
Porter-Duff composition rules (cf. CompositionMode).  So the blendColors is 
not "good enough for everyone", if everyone includes people needing 
gradients, and "good enough" subsumes "usable".

Note that I do not vote for immediate inclusion in kdelibs, but I bet there 
*are* quite some use cases to be found, in case someone takes the time to 
identify and port them.  The only counter-argument that could hold IMHO ist 
that mixColors() is a very efficient, but also quite trivial and hard to get 
wrong function, so maybe it's not worth porting?!

Ciao, /  /
     /--/
    /  / ANS
[prev in list] [next in list] [prev in thread] [next in thread]