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

[Kevin Ottens]

On Monday 6 April 2009 19:27:08 Alessandro Diaferia wrote:
> For me the default behavior should be KJob::EmitResult and not
> KJob::Quietly.. but those are just my 2 cents :)

That's your opinion now because you're looking at this particular problem. The 
thing to keep in mind is that most of the time kill() is called because of 
user cancellation, and most of the code out there just doesn't treat this 
special case of "error" (wouldn't make sense to duplicate the same if again 
and again right?). So what would happen if we made EmitResult by default is 
that in most cases of user cancellation, the user would then get a dialog 
claiming that the job failed... which isn't true, and isn't desirable to put 
into the face of the user (he knows he killed the task, he clicked on the 
button).

That's why EmitResult is a possibility but not the default, and shall not be 
the default. Now the apidox of the signals should be more explicit about that, 
and refer to kill(). It should also perhaps be made more explicit that 
finished() is not meant to be used outside of job trackers (although right now 
it's not gonna bite your head off if you do it).

And again, looking at the patch it seems that the problem is simply resetting 
the m_job pointer to 0 when the job deletes itself. There's a proper tool for 
that and it is called QPointer. So why not simply using that?

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/20090406/3c3e4fb7/attachment.sig>