What to do about KColor?

[Aaron J. Seigo]

who knew that blending and colourspaces were a topic of such passion for so 
many! =)

On Tuesday 29 May 2007, Germain Garand wrote:
> Le Dimanche 27 Mai 2007 01:35, Matthew Woehlke a écrit :
> > == Konqueror (4.0, already exists)
> > Needs HSL support for CSS3 conformance. I just thought of this, and so
> > have not checked if they already have a private implementation, or if
> > this would be an instance where KColor could provide a new feature.
>
> we do have a private implementation of a HSL to RGB converter in
> khtml/misc/helper.cpp

are you refering to the calcHue and qRgbaFromHsla methods in helper.cpp? if 
so, they represent a combined total of 17 LOC which is used  but twice, in 
cssparser.cpp.

> As far as khtml stands, having HSL in kdelibs would simplify this code.

according to my count, this is the first concrete use case that is already in 
svn and which really needs such colourspace support. it's also 452 LOC less 
than KColor and doesn't represent a class in our public API.

the implementation is already there so we're not in a bad place without 
KColor, though it would simplify things minorly and give this code a place it 
would be used. given KColor's memory usage and algorithms, i'm not sure it's 
actually a win at all, but it would move colour space code out of khtml in 
this situation.

KColor still needs an API review (ColorSpec when all the vars of that type are 
called space, for instance); it needs API docs and to be brought into line 
with the kdelibs coding style (braces, indent, dptr usage; this is a 10 
minute job however); nobody has actually done more than hand-waving about how 
this and pigment will compliment each other; KColor as a name has been 
objected to; we're very late in the 4.0 game for more kdelibs additions; the 
primary proposed use case for this (the usability and accessibility inspired 
extended palettes) is still also a proposal versus a work in progress at this 
point .... 

i'd be much more comfortable with this if there was either broad consensus 
(there isn't) and/or we were earlier in the release cycle. i guess i'm a 
little confused by the urgency and pressure being applied to such a feature 
which is clearly non-essential, if perhaps useful. but maybe that's just me.

> Also, I think that calling 500 lines of mathematical code bringing nice
> features a 'bloat' is not just preposterous. It's grotesque.

it is bloat if the features it brings are not used, will be duplicated 
elsewhere, etc. i know this conversation has been a belaboured one and so it 
is easy to lose track of what has been covered already.

> Your argument about the strengh of HSL with regard to lighten() and
> darken() is especially compelling, and is what convinced W3C too:

agreeing with the w3c is not a sure sign of the decision's sanity ;-P

-- 
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/20070529/d390fc0b/attachment.sig>