What to do about KColor?

[Matthew Woehlke]

Aaron J. Seigo wrote:
> who knew that blending and colourspaces were a topic of such passion for so 
> many! =)

I did ;-). (Yes, /before/ I suggested KColor I could have told you that 
HSV vs. HLS is a subject of potential Holy Wars.)

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

/me counts LOC to do only fromHls, without a class, using Ion's current 
implementation...

Looks like about 30, maybe a little under. khtml's implementation is 
less paranoid (fine for them, bad for a lib implementation), but is 
otherwise *identical*. :-) Which is actually a little surprising since I 
am almost certain mine was developed quite independently, I guess we 
thought of the same optimization tricks :-).

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

I would hope the compiler would optimize the heck out of the memory 
usage. :-)

What's wrong with the algorithms? Problems should be fixed, but no one 
has made specific comments of this nature (or they got lost in the 
general bashing).

> KColor still needs an API review (ColorSpec when all the vars of that type are 
> called space, for instance);

I blame indecision inspired by Qt, which uses 'spec', when 'space' is 
more appropriate :-).

> 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);

Of course it would be doc'd, and as you say style is trivial. My first 
concern was working code, doc changes are not BIC :-).

> nobody has actually done more than hand-waving about how 
> this and pigment will compliment each other;

I suggested making KColor private and later porting the front-ends using 
it to Pigment as soon as that is feasible...

> KColor as a name has been objected to;

...which would nullify this argument, I would think. (Although why does 
no one object to KoColor? Is the 'o' that differentiating, or will 
KoColor become something else in kdelibs? KPigment maybe? ;-) )

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

...and will stay that way until a: I am satisfied with the outcome of 
this whole discussion, or b: someone else decides to work on it.

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

Yeah, all the usability folks seem to have stopped complaining *shrug*.

>> 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

...but the usability article Germain Garand posted also agrees with 
using HSL. I would think it common sense that white and black are 'more 
contrasting' than blue and black. HSV does not convey this well, whereas 
HSL has a much more correct concept of brightness, and HSY even more so.

-- 
Matthew
"A mouse is a device used to point at the xterm you want to type in."
   --Kim Alm, A.S.R.