Moving ThreadWeaver to kdelibs

[Aaron J. Seigo]

On Monday 12 September 2005 04:28, Mirko Boehm wrote:
> I was approached by different people to move ThreadWeaver to kdelibs.
> Namely by kmail, kdevelop developers and by Thiago (but I forgot what he
> wanted to use it for).

you can likely add Plasma to that list, btw, as the plan is to fairly 
aggressively use threading to keep the GUI thread as free as possible so the 
UI remains interactive and artifact-free.

> Could you give me clues where in the accepted library structure it would
> fit in?

my personal suggestion would be to aim to have it included in kde-components 
as it has minimal dependencies as you note and is portable (AFAIK, anyways?), 
so it would fit in well there.

the outstanding issues i can see are:

documentation: there is some API documentation, but it isn't complete. and an 
introductory article (perhaps based on your aKadmey presentation?) would be 
invaluable. in fact, i'd like to see intro articles for every such component.

test coverage: there is a Tests/ directory, but the programs in there don't 
seem to be unit tests but rather example apps? unit tests would be required 
to make it into kde-components

API review: i don't know how much API review threadweaver has undergone. can 
you point us to projects using threadweaver now, or the opinions of others 
who have looked at it? (i haven't done anywhere near a thorough look at it 
yet, so if you smell a little hypocrisy in this point, you're right ;)

what are your plans for the above?

> And could someone help me to adapt it to the upcoming build system (it uses
> qmake only for now).

as much as i am famous for hating build systems, i'd be happy to do this with 
Makefile.am's, but as i understand it those are going away in kdelibs soon 
anyways so this would be wasted effort it seems... and i don't know much of 
anything about our brave new scons system (yet), other than Thomas Nagy being 
wildly excited about it ;)

> I would prefer to keep an individual library, as ThreadWeaver currently
> relies on QtCore only, which allows to use it in non-GUI applications.
> Please also refrain for now from adding dependancies to QtGui to the
> library itself, I think this should be put in some other KDE Gui library or
> another library by itself.

i think this is very sane =)

-- 
Aaron J. Seigo
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/20050912/d02f5d45/attachment.sig>