[PATCH] Take care also of the KJob::finished signal in KPart - it also fixes Ark's BUG 187538
ervin at kde.org
Wed Apr 8 09:25:05 BST 2009
On Wednesday 8 April 2009 09:50:03 Kevin Ottens wrote:
> On Tuesday 7 April 2009 11:49:22 David Faure wrote:
> > > That's why EmitResult is a possibility but not the default, and shall
> > > not be the default.
> > It was, in kde3...
> Then I wonder when it changed, because I really make it so that KJob
> behavior didn't break KIO::Job behavior...
OK, that was really bugging me, I had to take a look in the 3.5 branch... In
KIO::Job there we have:
virtual void kill( bool quietly = true );
So quietly wasn't the default back then. I guess I got the reasoning in this
thread wrong though:
- When kill() is triggered by some user input we want to indeed emit the
result as it's indeed compensated by by showErrorDialog();
- When kill() is triggered by some application code (which in its logic
decides to cancel a job without keeping the user in the loop) we generally
don't emit any result (the application is supposed to know what it's doing).
That's why quietly is the default as most app developers just call kill(), and
in the case of the ui bits (which are now the trackers shown to the user) we
have to explicitely request for emitting the result (as that's something the
application logic doesn't control).
I hope it'll share some light on the matter and we're all on the same page
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"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...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel