Moving ThreadWeaver to kdelibs

[Zack Rusin]

On Tuesday 13 September 2005 08:01, Stephan Kulow wrote:
> On Tuesday 13 September 2005 01:18, Thiago Macieira wrote:
> > Currently libkdecore depends on QtGui, but that's only for the
> > short term. The goal is to move everything depending on QtGui out
> > of it so that it depends on QtCore only. Therefore, your class is
> > suited for libkdecore.
> >
> > In the new framework, ThreadWeaver would be a Component.
>
> I suggest you put it as subdir to kdelibs and have kdecore link it
> in. We will do the sorting later. And please: stick to the naming
> within kdelibs - no capital letters. Or let someone else do the job

I think we talked about this during the conference: no (I'll repeat 
because the "no" is crucial) _no_ class will be moved to kdecore as a 
component without a staging area in a static library. If something will 
prove useful and will actually start getting used (plus will get some 
testing) then we move it to kdecore. We need to create a static 
libkdehelpers/libkdeextras/libkdebeta or something like that to stage 
those component and we might as well do it right now since this is the 
exact scenerio where we would like to use it.

Plus, this has the uncanny adventage that we can be breaking BC as the 
users of those components give us feedback on it.

Zack

-- 
The sum of the universe is zero.