[PATCH] Take care also of the KJob::finished signal in KPart - it also fixes Ark's BUG 187538
faure at kde.org
Wed Apr 8 17:22:13 BST 2009
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 );
> So quietly wasn't the default back then.
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).
More information about the kde-core-devel