What to do about KColor?

[Matthew Woehlke]

Since the underlying question got totally derailed, let's start over.

First: I fully intend that KColor is going into KDE somewhere (libs or 
artwork?) at some point (4.0 or 4.1?). Let's be clear on that.

Now... who needs it / would use it?

== Usability stuff (4.0 hopefully, medium-high desirability)
Needs some form of blend. KColor (HSL or HSY) preferable due to more 
accurate results and greater ease of use. This would in turn be used by 
Kate, KDevelop, Dolphin, and really any other application that does any 
sort of text color-coding. Use by /all/ KDE styles should be strongly 
encouraged.

== KUrlButton (4.0, already exists)
Needs some form of blend; porting target.

== KColorPicker (4.0 hopefully, "eye candy")
If KColor goes in I would like to at least look into adding HSL picking 
to KColorPicker. HSL is used on Windows, so an obvious argument in favor 
is that this means 'less surprise' for Windows users used to HSL.

== Konqueror (4.0, already exists)
Needs HSL support for CSS3 conformance. I just thought of this, and so 
have not checked if they already have a private implementation, or if 
this would be an instance where KColor could provide a new feature.

== KDevelop (4.1 we hope :-), medium desirability)
Wants blend or preferably the usability stuff, though not a show 
stopper. Currently KDevelop 3.4 has the old version from Ion's 
predecessor. Three-argument blend preferred.

== Plastik (4.0, already exists)
Needs at lest the 'bare minimum' blend() signature below or porting 
isn't worth it; porting target.

== Ion (4.1 hopefully, it's a style so "eye candy")
Needs at least the 'bare minimum' blend(), darken() and lighten() 
signatures below, either in kdelibs or else privately. Needs HSL, 
preferably HSY.

...and that's just what I know about currently.


Zack has offered an inflexible, slow, and harder (i.e. more steps) to 
use version of blend() that would be usable by KUrlButton and (with more 
work) the usability stuff. However as a result of... "friction" between 
myself and Zack, and the fact that I am more or less the only one 
pushing the usability stuff, there is a good chance that KUrlButton 
would be the only user of Zack's version in KDE 4.0. This means it is 
questionable if Zack's implementation meets the inclusion criteria.

I have offered a KDE-native version that isn't reliant on Qt (therefore 
can be extended in the life of KDE4 independent of bumping the Qt 
version requirement) and is suitable for all of the above uses. Current 
code is in playground/libs/ui/kcolor. Because people have expressed 
concern about maintaining BC, I propose the following:

Move darken(), lighten() and blend() to a namespace (I'm proposing 
KPalette) that will ultimately house the aforementioned usability stuff, 
and keep KColor private for now. Use the following signatures:

     static QColor blend( const QColor& c1, const QColor& c2,
                          double k = 0.5, double r = 0.5,
                          BlendMode mode = BlendNormal,
                          ColorSpec space = Rgb );
     static QColor darken( const QColor& color, double k = 0.5,
                           ColorSpec space = Hsy, double r = 1.0 );
     static QColor lighten( const QColor& color, double k = 0.5,
                            ColorSpec space = Hsy, double r = 1.0 );

...or, these bare minimum, less room for future flexibility signatures...

     static QColor blend( const QColor& c1, const QColor& c2,
                          double k = 0.5 ); // this is just *asking* to
                                            // be overloaded
     static QColor darken( const QColor& color, double k = 0.5,
                           double r = 1.0 );
     static QColor lighten( const QColor& color, double k = 0.5,
                            double r = 1.0 );

(Anything less than that means Ion forks this stuff. Anything less than 
the above version of blend() means Plastik doesn't use it and retains 
the current private implementation. Either way, KColorPicker and 
KPalette will most likely use the KColor methods these wrap.)

This does mean that ability to use HSL/HSY color spaces is restricted to 
kdelibs or using Pigment until/unless KColor is made public. Conversely 
it means that the implementation may be changed. Of course, we can also 
still change any of this prior to KDE 4.0 release.

-- 
Mathew
(sorry, .sig file is on the other computer)