[Development] RFC: QProcess variant or separate class for launching applications "GUI-style"
René J. V. Bertin
rjvbertin at gmail.com
Fri Jan 8 10:52:14 CET 2016
Thiago Macieira wrote:
> On Thursday 07 January 2016 22:14:47 René J. V. Bertin wrote:
>> is OS X really the only OS where there
>> exists a specific spawning API for GUI apps in addition to a more
>> traditional Posix one?
> The burden is on you to prove this class would be beneficial in cross-platform
> contexts too.
Of course (and that'd be fine as long as "you =/= me myself and I" ;))
But I'd hope this would be the best place to know if Qt supports (or plans to
support) platforms where there also exists a specific way to launch applications
so that they behave like GUI applications should behave on that platform. Or if
there are platforms where such a dedicated launch API will be introduced in some
nearish future (MS Windows or Android come to mind).
I suppose one could even consider the session management env.variables on
There's an alternative though, from which this whole idea sprung: let QProcess
itself determine if an app bundle executable is being started, and use
LaunchServices if that is the case - i.e. if the the command is either "foo.app"
or "/path/to/foo.app" or "/path/to/foo.app/Contents/MacOS/foo-bundle-exec". (the
latter is a bit tricky because you'd probably want to verify that it is indeed
the bundle exec that is being started.)
This has the advantage of being transparent and leading to expected behaviour
from the user POV, but there are some details to be worked out regarding
channels and possibly other QProcess features that cannot be supported this way.
Should be fine for QProcess::startDetached though.
What about the idea of a QProcess::startDetached variant that returns a QProcess
instance? That'd make sense (IMHO) if it's possible to provide (at least)
termination notification through the QProcess::finished signal - and I don't see
why the fact of starting something in detached fashion would make it
uninteresting to know if/when that process exits (e.g. to start it up again).
The question would be of course to what extent it is possible to support this on
more than a single platform.
> Not gonna happen. posix_spawn is too limited.
In what sense? Looking at the documentation it would appear the opposite, an API
with way too many options that have to be set correctly ...
More information about the Development