make fromHSL public, add toHSL

[Matthew Woehlke]

Thomas Zander wrote:
> On Wednesday 13 June 2007 09:25:33 Boyd Stephen Smith Jr. wrote:
>>> Last I heard the consensus was still that one color space for kdelibs
>>> is enough. Lets not open a new thread in a new week to try again.
>> So, you propose that KColorDialog on Windows simply re-implement and/or
>> copy-and-paste the code from KHtml? Â That sounds like a poor idea.
>>
>> Okay. Â That's a strawman, but I'd like to see a counter-proposal rather
>> than a just "don't do it that way".
> 
> Is "Use QColor" too obvious? ;)

Ok, you want to impose an unfamiliar color space on Windows users. 
Thanks for your opinion.

> It does support everything the color dialog needs. I wrote a color dialog 
> in another toolkit once, and you really don't need that much from the 
> existing color object. Just a proper conversion from HSV (or whatever you 
> are showing the user) to RGB and back.
> And QColor has that.
> 
> Matthew was asking for something he 
> knows is not required but he has asked for a public API for colors soo 
> many times [snip]

Um... no. I was asking about something I know /you personally/ are so 
wildly opposed to it almost feels like you're religious about it. Yes, 
there was a consensus against a certain class that I (because we are not 
talking about it) won't name. Like Olaf, I don't recall a consensus 
against HSL in general (not unless "Zack Rusin and Thomas Zander" == "a 
consensus"). In fact, a number of people have stated that they prefer 
HSL. Furthermore, both Redmond and WC3 prefer it, as do the Inkscape 
developers and PSP developers, and still others support both.

Anyway, I don't see the point in continuing this line of conversation. 
You obviously feel the need to make your opinion heard. Fine. To be nice 
to Windows users, I plan to, at some point, add a *private* HSL 
implementation to KColorDialog, which will then be redundant with the 
one in khtml. If that bothers anyone, it can be fixed later.

-- 
Matthew
Cannot read .sig now