[RFC] Color usability time...

[Matthew Woehlke]

Aaron J. Seigo wrote:
> On Monday 04 June 2007, Matthew Woehlke wrote:
>> Aaron J. Seigo wrote:
>>> On Monday 04 June 2007, Andreas Pakulat wrote:
>>>> As far as the question wether this is needed for KDE 4.0 I don't know,
>>> no.
>> Any reason to not at least add things we know will be needed, like shade
>> (and the various dark*/light* under it)? We already have at least a
>> request from dolphin for those, in addition to the obvious need (obvious
>> = set your window color really dark).
> 
> don't confuse the thread. Andreas was asking if colourspace support was 
> needed, not whether dark/like/shade/etc was needed.

Ah... my apologies.

> as you said yourself:
> 
> "Trying to work in HSV is 
> theoretically "do-able" with the help of qGray, but IMO the amount of 
> work required to 'guess' how much to darken/lighten a color doesn't 
> justify /not/ providing an HSY implementation"
> 
> so it is possible, even if your opinion you'd like it done otherwise right 
> now.

IMO there is no reasonable justification for trying to figure out enough 
of how Qt's darken()/lighten() work when we would be much better served 
by making public (only so khtml can also use it) what is already in 
khtml. I am still of the opinion that using HSY is a laudable goal. I am 
also of the opinion that I don't want to make my head hurt with linear 
algebra trying to twist Qt into a usable pretzel when khtml already does 
at least as much.

I think you might be reading in too much based on previous discussion :-).

Note: I'm also amenable to using HSL* now and revisiting HSY later 
(possibly when we can use pigment); I thought I tried to say that 
originally but I apologize if I didn't or if that was not clear.

(* Unlike HSV, the only problem with HSL is that it treats (255,0,0), 
(0,255,0) and (0,0,255) as all having the same brightness. This is 
wrong, but I'm going to stop there; there is enough color theory in this 
thread already :-).)

>>> ergo why consensus has been to be conservative on this as we grow towards
>>> a better understanding of what is really needed from these colors.
>> Honestly, I don't quite get the 'need for consensus' argument; we've
>> been over this twice before in the last several months.
> 
> yes, i know. and both times we actually arrived at "let's be conservative and 
> not go adding a bunch of colour space stuff to kdelibs". it seems you're 
> intent on repeating the conversation over and over until that gets changed.

It sounds like you are thinking about the KColor threads. I'm referring 
to http://lists.kde.org/?l=kde-core-devel&m=117538320017047&w=2 and the 
thread that predated that one and led to the creation of Olaf's document 
in the first place (I think that was on kde-usability only) for which I 
don't have a link handy. The only outcome of the k-c-d thread that I 
remember is a general waning of interest.

> in particular you say: "Said implementation will be lightweight and private"
> 
> which to me translates to "I'm going to put KColor in kdelibs, even though 
> we've been through this once already and it was turned down."

Actually, no, it translates into "what's in khtml" plus the inverse 
(IIRC khtml is only hsl->rgb?). I personally think KColor is "elegant" 
but everyone else obviously wants something more "lightweight", ergo 
code that looks like khtml.

> instead, let's concentrate on how the new palette's API will look like, get 
> some solid use cases to work against and start an implementation within the 
> bounds of what has been discussed to death already on this topic.

Agreed. I'll try to get some code ready later tonight.

-- 
Matthew
"In the beginning was the word, and the word was
content-type: text/plain" -- Martin Schulze