Problems managing KIO::Jobs

[A. Bikadorov]

On 04.12.2016 10:58, David Faure wrote:
> Indeed suspend() before starting wasn't implemented. It was only used
> internally for the bitburger protocol in CopyJob.
> 
> I have now at least implemented suspend()-before-start() in SimpleJob
> and FileCopyJob, in 
> https://commits.kde.org/kio/91fd82cc595a07549ef9da85079415497a7780ae
> (this won't be in KF 5.29, it's for 5.30)
> 
> So the above would work with KIO::file_copy, at least.
> KIO::copy is a different story, a CopyJob has no kioslave on its own, but 
> basically manages a state machine, so suspending anywhere in there and 
> resuming where we left off seems a bit tricky. The special case of suspending
> before starting is easy to implement though... done:
> https://commits.kde.org/kio/84d5c6c71d2f0e37ef4cc9c4349531ba088e2ae6
> 
> I'm afraid I can't provide you with any workarounds, other than not creating 
> the job until it should run.

I already managed to "solve" this in the meantime the way you proposed: job creation is
wrapped in another class and delayed.

Thanks for the patches, anyway. I think most important is that the behavior of
job->suspend() is well defined and returns the correct boolean in every use case.

> I suppose kuiserver gets the signals from the subjob, while you're listening 
> to the DropJob itself.
> 
> It should be easy to forward the signals in 
> DropJobPrivate::doCopyToDirectory().
> 
> Feel free to make a patch (or report a bug, but a patch is preferred ;) ).

Yes, I totally overlooked this at first but the patch is already pending now, see
https://git.reviewboard.kde.org/r/129540/

Thanks
Alex