[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 mailing list