KIO split (from the Job side)

Volker Krause volker.krause at
Mon Apr 17 21:56:34 BST 2006

On Monday 17 April 2006 18:47, Kevin Ottens wrote:
> Hello list,
> I'd like to propose some refactoring in the KIO::Job area. It's in my
> opinion particularly needed for the following reasons:
> 1) KIO::Jobs are tied to the UI and this depend could be removed
> 2) Other areas than KIO are starting to use Jobs (namely Akonadi and
> Solid), so it's a good target for factoring
> My current plan is the following:
> 1) Factor out a KJob class that will go in kdecore (find in attachment).

Looks good from the Akonadi point of view :)

One thing we have in the Akonadi job class is a synchronous convenience 

bool Job::exec()
  QEventLoop loop( this );
  connect( this, SIGNAL( done( PIM::Job* ) ), &loop, SLOT( quit() ) );

  return ( d->mError == 0 );

Might be interessting for KJob as well, it simplifies things eg. if you are 
using the job in a thread.

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 ;-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list