KColor is coming this Monday...
Aaron J. Seigo
aseigo at kde.org
Fri May 25 22:33:50 BST 2007
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
> ...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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel