KIO split (from the Job side)

Kevin Ottens ervin at
Tue Apr 18 08:37:37 BST 2006

Le Lundi 17 Avril 2006 22:56, Volker Krause a écrit :
> Looks good from the Akonadi point of view :)


> One thing we have in the Akonadi job class is a synchronous convenience
> method:
> bool Job::exec()
> {
>   QEventLoop loop( this );
>   connect( this, SIGNAL( done( PIM::Job* ) ), &loop, SLOT( quit() ) );
>   start()
>   loop.exec();
>   return ( d->mError == 0 );
> }
> Might be interessting for KJob as well, it simplifies things eg. if you are
> using the job in a thread.

Yes, noticed this one. I'll add it as soon as possible.
Just one question though, will it play nicely with deleteLater() though, since 
I use it in emitResult() (and KIO::Jobs are assumed to delete themselves).

> Hm, what about ThreadWeaver, IIRC it has a job class as well? Would be cool
> if KJobs and ThreadWeaver jobs would be at least compatible, using diffrent
> job systems inside each other is ugly, I know that from KNode ;-)

I discussed it a bit with Mirko, as far as I know it has mostly an impact on 
the scheduling of jobs, it's something not imposed by KJob. Currently I only 
want KJob to force a consistent job interface, scheduling and the way they 
are executed is a slightly different problem.
I agree that at one point we'll surely want to address this, but it needs some 
refactoring first in order to use ThreadWeaver correctly (IMHO removing the 
UI specific parts of jobs is of importance here).

Kévin 'ervin' Ottens,
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list