Re: Problems managing KIO::Jobs
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
Re: Problems managing KIO::Jobs
On lundi 14 novembre 2016 15:23:01 CET A. Bikadorov wrote: > 1. Creating and immediately suspending a job does not work as expected. E.g. > after > > KIO::Job job = KIO::copy(urls, dest, flags); > > bool result = job->suspend(); // returns true > > bool result2 = job->isSuspended(); // returns true > > the file copy operation is still starting. All progress signals > (description(), percent(), ...), are omitted until result() and finished() > are emitted. I'm sure this is a bug and can report it but would also like > to know a workaround to continue implementing a "job queue" (i.e. the user > decides when a job is started). 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. > 2. Similar to (1) DropJobs are never emitting any signals until finished(). > It must be possible somehow to monitor the progress of copy or move > operations because the notification widget does this. But I could not > figure out how plasma-workspace/kuiserver does this. 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 ;) ). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Problems managing KIO::Jobs
Hi, since there is no frameworks-users list and kde-devel seems less appropriate I'm asking here. I'm currently working on adding a job manager (similar to Plasma's notification widget) for KIO jobs to Krusader. While doing that I came across two issues which couldn't be solved yet. 1. Creating and immediately suspending a job does not work as expected. E.g. after > KIO::Job job = KIO::copy(urls, dest, flags); > bool result = job->suspend(); // returns true > bool result2 = job->isSuspended(); // returns true the file copy operation is still starting. All progress signals (description(), percent(), ...), are omitted until result() and finished() are emitted. I'm sure this is a bug and can report it but would also like to know a workaround to continue implementing a "job queue" (i.e. the user decides when a job is started). 2. Similar to (1) DropJobs are never emitting any signals until finished(). It must be possible somehow to monitor the progress of copy or move operations because the notification widget does this. But I could not figure out how plasma-workspace/kuiserver does this. Thanks for help! Alex
