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?
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
