make fromHSL public, add toHSL

[Matthew Woehlke]

Jos Poortvliet wrote:
> I sure wouldn't want to get involved in this, but I can't resist asking 
> what
> solution you then propose for the windows color picker and the themes and
> styles and apps like Kate who need this? They must copy-paste the code,
> right?

Um, actually kate doesn't need either color space, kate needs 
KColorScheme :-). Which we have already.

Ion does need HSL/HSY darken/lighten with saturation tweaking (the 
parameter Zack tripped over originally) which hopefully will be in 
KColorUtils (along with luma() and contrast()), but does not need the 
underlying space conversions. KColorDialog is the main 'needer' of HSL. 
The HSY need can, for now at least, be buried behind public interfaces 
(the aforementioned contrast(), darken(), etc.). I'm not convinced that 
there won't be a want for them, but we'll wait and see.

> Maybe Matthew can write the code he wanted in KDElibs but place it in
> playgroud, and then each of those who need it copy-paste it from there.

Unless people object to doing even that much (so far I haven't heard 
any), HSY will be in KColorUtils, privately, and HSL will be in 
KColorDialog, also privately (I might put both in a non-public header). 
So, yes, there will be "reference implementations" for people to copy.

> If it turns out there are enough users, it can get in KDElibs (before or
> after 4.0). If only 2 places finally need it, it won't.

Right. Actually, by staying private now, we may end up changing the 
implementations to use pigment in 4.1, and of course pigment will be 
available to all :-).

-- 
Matthew
So, an astrophysicist, a quantum physicist, and an astrologer walk into 
a bar...