[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KColor is coming this Monday...
From: Hans Meine <hans_meine () gmx ! net>
Date: 2007-05-29 14:44:16
Message-ID: 200705291644.17005.hans_meine () gmx ! net
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic