[RFC] Color usability time...

[Aaron J. Seigo]

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.

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.

> > 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.

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."

kdelibs is a *shared* body of work; shared by 1000s of people who use it. it 
also has a set of people working on tending to it and a release schedule to 
keep in mind. it's not an app with half a dozen developers where changes 
don't impact others. that's why there has been discussion and conclusions 
drawn as a group on k-c-d. let's not go through it again. 

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.

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070604/5ae6afcb/attachment.sig>