What to do about KColor?

[Aaron J. Seigo]

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.

> 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 
things easy.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070527/2a8cb438/attachment.sig>