KColor is coming this Monday...

[Aaron J. Seigo]

On Friday 25 May 2007, Matthew Woehlke wrote:
> Zack Rusin wrote:

> > Now moving forward to the blend method. I think it's a neat addition.
> > What I think is pretty silly is introducing another API and another
> > implementation on top of what Qt already does and provides.
>
> I've been asking for months where to find blend() in Qt. No one has told
> me, and I haven't found one. Therefore I fail to see how you can say

i believe zack showed you an example in his email, no?

> (Do we have a global KDE namespace? I.e. KDE::blend()?) 

no. but even if we did, that would be a poor idea to put such a general and 
context-free word into a global namespace. blendColors would make more sense, 
but then you're typing more again. and therefore the goddess invented 
autocompletion in text editors.

> > It's a really bad idea because it means that KDE
> > developers will by default use this class and when they do they introduce
> > losy conversions all the time. The bottom line is that to paint KDE
> > applications need to convert to QColor at some point anyway. So the usage
> > of KColor in most cases will be.
> > 1) Convert QColor to KColor (due to differences in the way these classes
> > internally store colors, that's already one lossy conversion)
>
> If you looked at the code for KColor and QColor you would know that this
> is actually totally untrue. QColor uses 16 bits to store color
> information (and frequently only 8 are set), whereas KColor uses
> something like 48*. Funny, that doesn't /sound/ lossy :-).

i believe zack was refering not to bit depth (and therefore how much 
information you can store) but to the process of converting from one color 
representation to another. converating between colour spaces is not something 
i'm very familiar with, but i am familiar with other types of data 
conversions where, due to representations, data is lost in the process when 
converting from one format to another. whether that's the case here or not is 
up to a domain specialist's knowledge; last i checked, that describes zack in 
this domain.

> ...or (and particularly for KDE5) KoColor and KColor can merge. Actually

if that is indeed a rational goal, then why not work to make Pigment ready for 
kdelibs so that we don't end up with cruft so soon into the kde4 series?

we can wait for 4.1 for such functionality. yes, i understand kdevelop needs 
this right now; perhaps it use a copy of it internally for now. and AFAIK 
kdevelop is aiming for 4.1 anyways, no?

this brings us back to where we were before, with one addendum: a blend 
function in kdelibs that wraps an implementation for doing so is interesting 
and welcome. a more focussed name than KColor has been requested, which seems 
fair enough, and an alternative has been suggested. complex colour space work 
should merge with Pigment and be readied for future kdelibs releases.

so you get a blend method and a way forward towards making it all that you can 
dream. it just doesn't come with a class called KColor in 4.0.

is that a fair compromise that meets the expectations of people?

-- 
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/20070525/738262c8/attachment.sig>