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