Color manipulation functions in kdelibs?

[Matthew Woehlke]

(Again, I'm going to break this into two pieces. The usability folks 
should be CC'd on the second.)

Zack Rusin wrote:
> On Thursday 14 December 2006 11:54, Matthew Woehlke wrote:
>> It has to be done in HLS/HSY space [snip]
> 
> That's a purely semantically problem. I don't see any problem with adding 
> lightHLS, darkHLS or ever changing those two methods in QColor itself. It's a 
> trivial patch. 

Ok... so I am confused. Are you, or are you not against adding HLS 
support to QColor? To date you have seemed (to my reading) to be 
against, but the above statement would necessarily contradict that.

I would change the methods to accept a spec as an optional argument (or 
more preferably, add an overload that takes a qreal, an optional spec 
(even default it to RGB or HSV if you like! :-)), and an optional second 
argument to fiddle with the S component as well as the V/L/Y.) I say 
that because I have a particular use case where I need to fiddle with 
the saturation independent of the luminance, but I'm OK needing a 
private function for that particular use (and actually, I only use it in 
exactly one place, and only for lighten()). The default behavior is of 
course to leave S alone.

HLS lighten()/darken() are pretty trivial. HLS (and especially HSY) is 
slightly less so. :-)

>> I thought we were agreeing here?
> 
> Really? I'm sure I never, ever supported duplicating functionality from Qt in 
> KDE when a trivial thing was missing in Qt. 

I guess I'm confused. :-)

>> Because I want HLS-true lighten/darken, which are also distinct from
>> what QPainter does
> 
> We do? Then surely we can accept that feature request and expose those in Qt.

Well, /I/ do, and I think/hope that if they were around, other people 
would use them.

>> Did you look at alphaBlendColors in Plastik? 
> 
> Yeah, don't see a problem with it.

I do. :-) The problem is that it is in Plastik, and not a lib. :-)

>> Did you look at the KDevelop patch (now checked in) that I referenced? 
> 
> Nope, if you can show me the diff that'd be great. 

The patch can be found at http://bugs.kde.org/show_bug.cgi?id=138730 
(either in the attachment form, or now in the commit log) - specifically 
the second and third change sets - which was in a previous mail. 
Incidentally that's my (fp-precision) version of the basic (RGB) blend 
code, if you would like to use it. :-) (Please feel free to do so!)

In fact, if you s/double/qreal/g it is probably better to use mine than 
Plastik's because it will preserve more precision of Qt4 QColor's 16-bit 
internal storage. Or, of course, write yet a third one that works 
directly with the internal values (possibly providing a qreal version as 
well as an unsigned char version for the input factor).

>> as number four), and that's without /trying/ to find examples. How many
>> do I need to find to convince you that this should be available in a
>> major library so that people don't have to keep re-implementing it? 
> 
> Two good would be enough to have me expose blend methods, I think I'm 
> convinced that I should just make light/dark from QColor do proper 
> lighting/darkening of a color. I'm assuming the latter would be enough to 
> just end the discussion, right?

No, because all of my examples are using blend to blend distinct colors, 
not simply make them lighter or darker. But they are also all RGB blends 
which are trivial to do. And I'll shut up now given your final comment. :-)

I would of course be very happy and grateful if light() dark() were 
"better" :-). I would also be happy to share my code with you if you like.

>> This seems to me like such a /basic/ (and trivial) functionality that I
>> don't understand why it doesn't exist yet in a standard library.
> 
> Yeah, maybe you're right. It's simply that no one asked for everyone just went 
> ahead and implemented their stuff. If that's what people want then I don't 
> think anyone minds having all those people keep their code and if we agree 
> that KDE actually needs it and it's a core functionality, them bam in Qt it 
> goes.

That would be my thought. I am pretty sure I wondered about it not being 
in any lib when I first had need of it (and I *know* I went looking for 
a lib version when I wrote that KDevelop patch). Maybe because it *is* 
pretty trivial, no one bothered to complain before? :-)

Thanks. :-) And please ask if you want any handy code.

-- 
Matthew
What? This signature /again/?