What to do about KColor?
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
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