KColor is coming this Monday...

[Hans Meine]

Am Samstag, 26. Mai 2007 19:53:38 schrieb Zack Rusin:
> > If you're going to continue this tirade, at least a: do your homework and
> > base your arguments in fact and not outright fabrication, and b: leave
> > your condescension of /other developers/ at the door.
>
> I'm not sure how this came out to be a personal attack on me, especially
> given that I absolutely never did a or b, but I certainly don't have time
> for a flamewar, so yeah, bye.

What a pity that you're leaving the discussion; you wrote exactly what I 
thought (and wrote earlier) about Matthews proposal.  I also have some 
expertise in respect to graphics and colors, and I think:

* Nobody will disagree that there are a lot of use cases for blending in KDE.
  However, there are only very few specific examples, and I would especially
  like to have a high level no-brainer API eventually, like "given this fg/bg
  colors, gimme some reddish text color that is still readable", or simple
  alpha-blending functionality (note the existing Qt API and CompositionMode
  enum).

* I neither like a 8*8-byte-doubles KColor representation nor an API with > 5
  parameters.  [read http://doc.trolltech.com/qq/qq13-apis.html]

* Matthew repeatedly writes questionable statements, like multiple instances
  of "xxx cannot be done with yyy", which is often quite wrong - it is only
  not as easy.  For example, the whole "blending in colorspace FOO" topic:
  Not all composition modes make sense in all colorspaces, and such a
  flexibility is absolutely unneeded for most applications (thus, in kdelibs
  IMHO).  Also the following "no default" comment is really ridiculous:

Am Sonntag, 27. Mai 2007 05:06:18 schrieb Matthew Woehlke:
> Calling Zack's looks like this:
> QColor foo = <something>;
> foo.setAlpha(<blend amount>); // no default
> KGraphicsUtils::blendColors(bar, foo);

  Of course one could add a 50% default, and the resulting API would be not a
  single bit more complicated than the one he proposed below.  I find it a
  pity that he scared off Zack instead of listening to his good comments.

In the end, I think that Matthew puts a lot of energy into the blending topic, 
which deserves respect, but I have concerns that the current code is simply 
not in a good state neither API-wise, nor technically [read 
http://www.poynton.com/ColorFAQ.html], and that one needs to identify real 
(application-specific) problems and find and review usable, tested solutions 
for them before one can try to find common patterns and introduce 
kdelibs-code.

Ciao, /  /
     /--/
    /  / ANS