Review Request 129540: DropJob: emit started copy job after creation

David Faure faure at kde.org
Mon Dec 5 08:57:18 UTC 2016



> On Dec. 4, 2016, 5:50 p.m., David Faure wrote:
> > I would prefer the subjob to remain an implementation detail. Just like so many other KIO jobs which use other jobs internally.
> > 
> > Instead this code should connect the signals from the subjob to the DropJob signals. Much like FileCopyJobPrivate::connectSubjob() does.
> 
> Alex Bikadorov wrote:
>     Maybe the description was misleading. I do not only want to monitor the subjob but also have full control over it. I.e. I need the signals/methods
>     
>     * description()
>     * percent()
>     * suspend()
>     * suspended()
>     * resume()
>     * resumed()
>     * result()
>     * finisned()
>     * warning()
>     
>     Do you really want me to connect/wrap all this?
>     
>     Also, I don't understand why plasma/kuiserver can have access to the subjob (via KIO::getJobTracker) but my application (Krusader) can't have it.

Well, suspend/suspended/resume/resumed/result/finished (as well as infoMessage and speed) should be handled already via KIO::Job's support for subjobs. description and warning are arguably missing in KCompositeJob::addSubjob.

But after further research, I changed my mind. I was about to reply that full encapsulation was better, because not all DropJob instances lead to a CopyJob (e.g. dropping files onto an executable), and that the DropJob itself should register to kuiserver rather than the underlying CopyJob... but there's a comment in the code about why we can't do that: DropJob can trigger a copy/move/link popup, and we can't have a progress dialog at the same time.

So OK, DropJob is a meta job around a few things including a CopyJob, and we can give the CopyJob pointer up to the app, with documentation that explains that it might not always be emitted, it all depends on what we're dropping onto.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129540/#review101272
-----------------------------------------------------------


On Dec. 4, 2016, 7:22 p.m., Alex Bikadorov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129540/
> -----------------------------------------------------------
> 
> (Updated Dec. 4, 2016, 7:22 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> -------
> 
> For giving an application a chance to monitor and control the subjob.
> 
> 
> Diffs
> -----
> 
>   src/widgets/dropjob.h 5c9bf10ecc34282d9acb50cef93e7bc8665cb904 
>   src/widgets/dropjob.cpp 1febd3397ec8e993a9786547da9c381a0f57a1f8 
> 
> Diff: https://git.reviewboard.kde.org/r/129540/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alex Bikadorov
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20161205/b85aafc0/attachment.html>


More information about the Kde-frameworks-devel mailing list