What to do about KColor?
mw_triad at users.sourceforge.net
Wed May 30 02:37:27 BST 2007
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
> 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
/me counts LOC to do only fromHls, without a class, using Ion's current
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
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
> 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.
"A mouse is a device used to point at the xterm you want to type in."
--Kim Alm, A.S.R.
More information about the kde-core-devel