Color manipulation functions in kdelibs?

[Matthew Woehlke]

Aaron J. Seigo wrote:
> On Monday 11 December 2006 13:51, Matthew Woehlke wrote:
>>> This might also be better placed in the QColor code - have you submitted
>>> a wishlist item to the Trolls?
>> Perhaps, but then you are tying KDE4 to a version of Qt that does not
>> yet exist, and also relying on Trolltech to maintain the functions we
>> need. Is that really a good idea? 
> 
> at this point I'm assuming we're going to need/want things in 4.3. that said, 
> letting TT carry library load on their shoulders is not a bad thing. they 
> have more manpower for libraries than we do.

Hmm. Ok, agreed, but this still feels like something that's likely to be 
rather volatile for being in Qt (or, something where we would wind up 
having trouble getting timely upgrades). If you read my reply to 
Clarence, do you still this is something that should go in Qt? 
(Actually, QHdrColor would be nice, but I still think we might wind up 
with a blend* in kdelibs. Maybe I am wrong?) Honestly, I don't have 
experience with TT, but I wouldn't expect it to be quite as fluid as KDE.

(Also, apologies for getting people's names switched; I meant to say 
'Brad' everywhere I wrote 'Clarence' in that message. Oops!)

>> It is my understanding that 
>> historically KDE has not been tightly tied to a particular release of
>> Qt. 
> 
> we've often required a specific version (or greater) of Qt.

True, but as mentioned, it has been my experience that upgrading KDE 
(mind, I'm not talking about 2.x to 3.x, I'm talking 3.4 to 3.5.5) 
usually does not require updating Qt. That is, once I install KDE x.y.z 
incident to installing a major distro, there is a certain expectation 
that I will be able to upgrade KDE to x.a.b for some time before needing 
to upgrade Qt.

-- 
Matthew
"Lost a planet, Obi Wan has? How embarrassing..."
  -- Yoda (Star Wars II: Attack of the Clones)