What to do about KColor?

[Aaron J. Seigo]

On Sunday 27 May 2007, Boyd Stephen Smith Jr. wrote:
> What to do about KColor?':
> > On Sunday 27 May 2007 01:35:54 Matthew Woehlke wrote:
> > I find it admirable that you have such a long breath; well over 100
> > messages have been written on 2 threads and a lot of them have stated to
> > have some sort of issue with your proposal.
>
> Matt is passionate about this, that much is clear.  Of course, lets not let
> passion get the in way of good code.

=) to both sentences ...

> > Just the advice of the say is that you should really listen to the
> > advice of many people that gave feedback in the other threads. This is
> > not politics where trying again in the hope to get people to give up
> > resisting.
>
> He's refactored the code so that the KColor class is an implementation
> detail, instead of a publicly exposed API and also disclosed signatures
> for his lighten and darken.

which is cool; that was, actually, my suggestion to him as a way to make it 
more palattable (haha) ... however, it was then pointed out that the need for 
HSL is pretty limited. -if- we end up with real use cases (e.g. code that is 
going to make it through kde 4.0/4.1) where it will make a real world 
difference, then we can always go back to this route. in the meantime we 
avoid an extra 500LOC in kdelibs that we aren't sure we need yet.

yes, conservativism.

> > * The blend feature can be implemented to everyones (but yours)
> > satisfaction using QColor.
> > * KColor (and HSL) is not needed and not wanted for this blending.
>
> I completely disagree. HSV (and hell even stupid RGB) blending/other
> operations can give good results sometimes, but just earlier this year I
> was going to do some KDE skinning and needed HSL/HSY color to get the
> right results.
>
> Lighten and darken look better and give more usable (as in usability)
> blends when done in HSL rather than HSV.

it depends on the brightness of your original colour and whether you are 
darkening or lightening. they both have tradeoffs. moreover, the question is 
do we care for the use cases, and the problem is that:

- many of the use cases currently in svn are bad hacks to get around 
limitations in qt3's qpainter that no longer exist in svn
- many of the valid use cases aren't actually implemented yet so we can 
experiment with them =)

-- 
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/20070528/8f96c76a/attachment.sig>