What to do about KColor?
Aaron J. Seigo
aseigo at kde.org
Mon May 28 01:04:04 BST 2007
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
> 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.
> 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.
> Matthew already stepped down to an implementation that doesn't introduce
> a full new class but instead just a namespace with 3 functions. I have
yes, i think Matthew was quite accomodating in that process. though i'm sure
his "i'm going to have KColor in KDE no matter what" statements probably
didn't help his case a lot, to be honest. =)
> to say that I personally don't care too much about wether a red error
> message is really bright or dark red, or wether a warning is more orange
> then a light red, but this disucssion IMHO wasn't really fruitful and
> hasn't brought any good to KDE.
yes, it was very inneficient. and not even the good kind of inneficient (yes
there are good kinds of that). there's something about restarting threads,
going back and forth over and over, ad hominym jabs, etc.. that don't make
i am glad that such occurances tend to stand out as odd rather than the way
things usually happen.
i'm not glad that we don't have a better way to handle these situations. this
is where an active "technical working group" that has the backing of the
community would have been astoundingly useful.
chalk one up in the "lessons to learn from" column =)
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel