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

[David Faure]

On Wednesday 08 April 2009, Kevin Ottens wrote:
> 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 );

OK.

> So quietly wasn't the default back then. 

s/wasn't/was/.
You're right, it was the default at the C++ method level.
What I had in mind when saying "it was the default" was rather "cancel emitted result",
but I should have phrased it differently indeed.

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

Thanks for the additional analysis, it confirms the fix that is now in svn.

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).