[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE/kdelibs/kdecore/jobs (silent)
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2009-06-29 20:46:53
Message-ID: 20090629204653.GB22876 () trinity ! apaku ! dnsalias ! org
[Download RAW message or body]

Taking to kde-devel as this might be interesting for other developers to
read.

On 29.06.09 15:15:03, Ramon Zarazua wrote:
> On Monday 29 June 2009 07:54:27 am Kevin Ottens wrote:
> > On Sunday 28 June 2009 16:36:33 David Faure wrote:
> > > On Sunday 28 June 2009, Ramon Zarazua wrote:
> > > > -     * @note: Deletes this job using deleteLater().
> > > > +     * @note: Deletes this job using deleteLater(), this function will
> > > > NOT return from +     *        your worker method.
> > > >       *
> > >
> > > What do you mean by worker method? And by "not return" ??
> > > Surely emitResult() returns. I don't understand this docu change.
> >
> > Hmm, it indeed makes no sense to me. The other bit of change (swapping
> > "delete" for "suicide") seems also wrong.
> >
> > I'd propose to just revert this commit if we don't get some explanation
> > about the intent of it.
> >
> > Regards.
> 
> Well here is the experience I had: What I gathered from the documentation is 
> that start should call another worker method through the event loop.

Not necessarily, you can just as well put your work into a separate
thread or separate process. The reason why you don't do the huge work
inside start() is such that you don't block the GUI. (Hence just calling
your worker method with a timer won't improve things, you'll also need
to split up the work into chunks).

> I tried calling it with QTimer::singleShot, however I could not get it
> to work.

Well, what failed? Did the slot never get called? Did you make sure your
signal was emitted and your job lived long enough?

> Afterwards I realized that emitResult() was not instantly suiciding the job as 
> I was led to believe. I asked around a bit on kde-devel(mentioning that I 
> could not get it to be called through the event loop), and I was told that it 
> doesn't matter, and that return should be called. If I was misinformed I 
> apologize in advance, however that means that documentation is still not 
> completely clear.

So you called emitResult() from inside start()? Well then of course
your actual worker method won't be called because the job considers
itself done.

I also don't understand what you mean with "will not return from your
worker method". If the worker method calls emitResult, then it should
have a return statement directly after emitResult. And that will work.

Also as I said, it might not be a timer-triggered worker method, but
could just as well be a separate thread or QProcess executing an
external process.

Andreas

-- 
Don't kiss an elephant on the lips today.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]