What to do about KColor?
Aaron J. Seigo
aseigo at kde.org
Wed May 30 01:29:14 BST 2007
who knew that blending and colourspaces were a topic of such passion for so
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
> 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
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
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel