D28020: New class ProcessLauncherJob in KIOGui

[David Faure]

dfaure added inline comments.

INLINE COMMENTS

> davidedmundson wrote in kprocessrunner.cpp:194
> It's the DBus calls that come before start that I want to get async, not the tiny bit between fork and the child process exec()'ing.
> 
> Obviously we can do that piecemeal later, and it isn't a reason to delay this.
> 
> I'm not sure how much of that we'll be able to get both async and into this "waitForStarted" pattern without event loops, but worst case we can do it for KF6. It's all a bit frustrating as FWICT no-one even uses the returned PID.

Ah you mean inside DesktopExecParser? I thought about that, but it's easier to fix later when the other users of DesktopExecParser (which need sync) don't exist anymore.
Otherwise we need to fork it into an async variant, not sure I'm motivated for that myself (especially for FUSE stuff...).

Yes, waitForStarted will also disappear in a pure-async KF6 world for this class.

And at least until KF6 we can port all apps to ProcessLauncherJob already.

Interesting point about the PID being useless, I never thought that this might be the case. But indeed, why would one need this...

> davidedmundson wrote in krun.cpp:488
> or we can just ignore it if we're phasing out klauncher anyway?

Right. Separate issue though. I like incremental steps.

REPOSITORY
  R241 KIO

BRANCH
  2020_ProcessLauncherJob

REVISION DETAIL
  https://phabricator.kde.org/D28020

To: dfaure, apol, davidedmundson, nicolasfella, vkrause, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200318/3eece62a/attachment.html>