[PATCH] Take care also of the KJob::finished signal in KPart - it also fixes Ark's BUG 187538

[Kevin Ottens]

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 
now. :-)

Regards.
-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090408/8b27c42a/attachment.sig>