What to do about KColor?

Andreas Pakulat apaku at gmx.de
Mon May 28 01:36:07 BST 2007

On 27.05.07 18:04:04, Aaron J. Seigo wrote:
> On Sunday 27 May 2007, Andreas Pakulat wrote:
> > a) we lost a rather dedicated developer (Matthew was pretty active in
> > Kate and contributed much of the forthcoming KDevelop4 VCS API).
> Matthew has decided to not work on Kate, KDevelop, etc? hum. that'd be 
> unfortunate.

Unfortunately, I hope he doesn't do this for a long time, but for now he

> > b) everybody who wants to blend two colors now has to do 3 lines of code
> > (as Matthew showed) instead of just one.
> that's a 5 line patch to fix if it is an issue: a convenience method that 
> takes care of creating the temporary colour for you. it'll be interesting to 
> see if that's really an issue or if in use (a) people don't care about the 
> extra lines or (b) they blend colours which are temporary objects anyways and 
> therefore don't need to store/keep one of them. so this may be a moot point, 
> or it could be a pain. we'll have to see; there's a solution in any case.

Well, its not just about having a temporary color but having to know
that I need to set an alpha value on that color and having to know that
alpha ranges from 0-255 (I actually had to look that one up to make
sure) is the issue here, IMHO. I know there's an easy way to have

blend(QColor, QColor, double, CompositionMode)

so why wasn't that one chosen instead? IMHO it makes much more sense.

> > From looking at the api docs 
> > it seems an alpha value of 128 would do the same as a .5 blend factor in
> > Matthew's API.
> that's correct; though this does it without an extra 500LOC class behind the 
> scenes. the demand for the features that KColor brings seems to be limited to 
> the people who are already looking to (and working on) pigment.

I can agree on that.


You will be awarded the Nobel Peace Prize... posthumously.

More information about the kde-core-devel mailing list