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

[Alessandro Diaferia]

2009/4/6 Raphael Kubo da Costa <kubito at gmail.com>

> 2009/4/6 Alessandro Diaferia <alediaferia at gmail.com>:
> > And so, couldn't we make kill() emitting result() ?
> I don't know whether the current behaviour in KJob is wrong or not -
> KJob::kill() does emit the result signal, but only when called with
> KJob::EmitResult instead of KJob::Quietly. If you make kill() emit
> result every time, there's no point in making the distinction between
> KJob::EmitResult and KJob::Quietly.
>
> > Or, at least apidox should be updated and somehow connect to the job
> deletion in the ReadOnlyPart class..
> There's another solution proposed by Aaron Seigo that would be
> creating another slot in KJob that would call kill(EmitResult), but it
> sounds a little hackish too.
>
> I think we first need to settle on where the problem actually lies -
> is it in KJob::kill's behaviour of not always emitting both finished
> and result, or is it in KUiServerJobTracker's way of connecting its
> stop button's clicked() signal, or even the signal connection in
> ReadOnlyPart?
>

For me the default behavior should be KJob::EmitResult and not
KJob::Quietly.. but those are just my 2 cents :)

-- 
Alessandro Diaferia
KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090406/4d5148a1/attachment.htm>