[KDE/Mac] QProcess for GUI apps on OSX (Re: closest equivalent to KApplicationPrivate::init() ?)

[David Faure]

On Sunday 03 January 2016 11:11:48 René J.V. Bertin wrote:
> On Sunday January 03 2016 10:22:27 David Faure wrote:
> 
> >> You saw I said "wait for QProcess to be improved", right? I don't expect a patch for QProcess to be incorporated before 5.7.x ...
> >
> >Patience is a virtue :-)
> 
> Oh indeed it is ... and getting a [real] life waiting for something this central to appear in a release version has its advantages too :P
> 
> >> Ok, so what about the requirements on QProcess? Anything beyond what's possible with QProcess::startDetached and possibly launch confirmation? Should QProcess figure out transparently (or rather, opaquely :)) whether to use LaunchServices or not, or should the developer be given a way to override it, or even switch to switch to LaunchServices rather than using standard Posix APIs?
> >
> >Those are implementation details.
> 
> Yes, of course. You were hinting at that I start drafting a patch for QProcess, no? Or do you have a Mac yourself on which to cook one up?

I'm letting you do this, just providing input.

My line above is because you asked "what about the requirements?". So I thought we were talking about features and therefore API (not about implementation).
>From the API point of view, your suggestion of NativeLaunch vs PosixLaunch is horrible in my opinion.
As a developer, I don't know what difference this actually means, and even if it was fully documented what effect this has on
OSX and Windows, maybe my conclusion would be "I want the NativeLaunch on Windows and the PosixLaunch on OSX",
therefore it would be fake cross-platform API because I would end up with an #ifdef anyway....
Ideally I was hoping for something more feature-based like a flag for "GUI app, bring the window to the front if possible".
Such a flag would make sense for all platforms where a specific call to QProcess is being made.
But of course it might be that LaunchServices is so different from the posix way that it's really a bigger switch with lots
of behaviour differences which cannot be described as a simple feature-based enum. That's unfortunate. Is there any
chance for a less intrusive solution to make QProcess bring up the window?

Otherwise I have another idea, calling the flags NormalLaunch (the current behaviour) and DetachedLaunch.
Then it's clear that there's no stdin/stdout/stderr handling since it's a detached launch, which can then be
implemented by LaunchServices on OSX. And it wouldn't be a new notion since startDetached already
exists.

> You didn't answer my other question. Do you have sufficient overview of the various places where QProcess is used to know if there is any call for features other than starting, stopping/terminating and waiting for confirmation that the process is running? And about that last aspect, should that be an indication "the process is all up and ready for interaction" or just "the process has been launched successfully and is or will be available shortly"?

If you look at the way krun.cpp uses QProcess, it answers the above: start, waitForStarted(), getting PID with processId(), and notification of exit with exit code
(among other things, to terminate startup notification). [1]
This means startDetached is not good enough, btw, I realize now: we need to get notified when the process exits.

Wild idea:
 startDetached(const QString & program, const QStringList & arguments, 
                            const QObject * receiver, const char * member,
                            const QString & workingDirectory = QString(), qint64 * pid = 0)

where the added receiver and member work like in QTimer::singleShot (with an overload for a member function etc.),
and that slot is called when the process exits. Downside: unlike QTimer, the slot has (can have) two arguments (int, QProcess::ExitStatus).

At this point I suggest to take it up to the qt development list.
- Write your findings about QProcess not bringing up GUI apps to the front (make sure to write and attached a self-contained testcase to verify that 100%)
- Suggest the DetachedLaunch flag, documented to be incompatible with any use of stdin/stdout/stderr....
- Suggest the static startDetached with slot idea.

API wise, the whole point of DetachedLaunch compared to startDetached (in addition to the OSX difference) is
to get the signals started(), error() and finished(), even for a process that will "run in its own session and act like a daemon",
i.e. which will potentially survive the current process (quite common when launching GUI apps).
I think I like the DetachedLaunch idea, but I can see how someone might argue that a flag that breaks half of the QProcess API (channel handling) is not a great idea.
Still, could be documented, and it's the only way to still get signals (we need a QProcess instance for that).

OK this leads to another wild idea:

- a new QGuiProcess class, tailored to starting GUI apps:
    No channel handling.
    Always start detached (i.e. killing current process won't kill secondary gui app).
    And always uses LaunchServices on OSX.
Maybe all the above is just the reasoning that justifies having a separate class, to avoid having methods that don't apply.

[1] (BTW a notification that the process is all up and ready for interaction is, I think, impossible technically, we don't know what the app is doing; anyway, not needed).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5