[Development] RFC: QProcess variant or separate class for launching applications "GUI-style"

[René J.V. Bertin]

Hi,

An idea has come up, discussing with David Faure to develop a QProcess variant or a separate class ("QGuiProcess") to allow dependent code to start applications in proper fashion, taking platform specifics into account, such that the new application opens the way users of the platform would expect.

For instance, starting an OS X application with a system() or fork()/exec() causes that application to open in the layer behind the one occupied by the calling process. This is easiest to see when starting an application from a terminal, say

%> /Applications/Safari.app/Contents/MacOS/Safari

the safari window(s) will open behind the terminal.
I presume this is common enough knowledge, but can of course provide a very simple QProcess-based demonstrator.

This is undoubtedly one of the reasons why the QCocoaIntegration ctor does an "activateIgnoringOtherApps" to bring the new application to the foreground forcibly [1]

It is not impossible to bring a different application to the front but the ideal way on OS X to open applications for GUI use is to use LaunchServices. This causes them to open in the foreground layer, unless another application is moved to that layer after the new process has been started. For instance, opening Safari via Finder or Dock will cause it to open foremost, unless you click on, say, your email client immediately to go back to whatever you were doing.
This provides a good balance between delivering a newly launched application ready for use (= in the foreground) and preventing focus stealing.

LaunchServices should support most if not all features currently available for applications started with QProcess::startDetached, and it should also be possible to provide termination/exit notification through NSWorkSpace. One could thus imagine documented tokens like QProcess::NormalLaunch vs. QProcess::GUILaunch where the latter leads to the use of LaunchServices on OS X, for instance

QProcess *QProcess::startDetached(QString &program, QStringList &args, QProcess::LaunchType type)

Returning a QProcess instance here would allow parents to be notified of child termination the same way that is possible with "non detached" QProcess instances (and remove the need for the version that takes a pid* argument).

The alternative would be a separate class (say QGuiProcess) that always uses LaunchServices on OS X. The documentation would discuss details like the fact that LaunchServices will invoke Terminal.app when used to start a shell script.

I'll be letting these thoughts mature before I start drafting an implementation, but it'd help to know if such an evolution or new class would be acceptable in Qt. It'd also be nice to know if something like this is already planned or under development, of course.

Thanks,
René

[1] Side-note : that doesn't always cause the menubar to appear, for some reason, possibly because the activate message is sent too early?