KIO split (from the Job side)

[Volker Krause]

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 
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.

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

regards
Volker
-------------- 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/20060417/fdcd2f43/attachment.sig>