QProcess for GUI apps on OSX (Re: closest equivalent to KApplicationPrivate::init() ?)

[René J.V. Bertin]

On Tuesday January 05 2016 12:55:57 David Faure wrote:

> I'm surprised it's that complex, and that an OSX app cannot launch another one and have it appear in front.
> Is there no app with an action that starts a calculator, a special-character selector, etc.?
> Is there no alternative application launcher? ...

Those would be written using platform-specific (native) APIs, not a middleware like Qt. 
It's pretty much a sign that Qt's OS X platform integration layer does a "come to the front ignoring anyone else", which is not exactly the preferred way of activating oneself.

I'm attaching a hack I wrote a while ago, an alternative to the standard "open" utility. It lacks comments, but should be readable enough. It also uses deprecated concepts like PSNs, but I presume modern alternatives exists to everything used in there. It has a feature to catch termination of the spawned application; evidently this is possible since even "open" itself can do so to behave as if the GUI application wasn't detached at all.
> This assumes that such messages can be captured from *another* process (the Qt app). From your description, it doesn't sound like that's the case,

See the attachment for a way to do this from within the calling application. The alternative would be to let the spawned application send some kind of Qt signal to its "parent", but that's probably not as easy as using the native mechanism.

BTW, I'm using a very nifty ObjC feature in that code, extension of an existing class instead of subclassing it or creating a whole new class.

> SIGCHLD is the posix way for a parent process to know that a child process just exited, but that's not available for "detached" processes (not children),
> and probably not when using LaunchServices either (also not a child).

Indeed.

> If you want to hack one instead of the other for experimentation purposes, why not, but I don't think it will make it any easier to work on the wrapper
> (which has no access to the QProcess internals).

We might not need access to those if we can override certain things from QProcess. To be seen in practice; KCoreAddons *is* a lot less overwhelming to start hacking around in of course.

> > There's the issue with LaunchServices delegating to Terminal.app for certain applications, but one could say that's a side-effect users of QGuiProcess will have to take into consideration.
> 
> That sounds like an expected result of GuiLaunch or QGuiProcess. You ask for a GUI, you start a commandline exe, you get a GUI terminal running that command.

Yes, agreed. I was thinking about code using the class; it'd probably want to assess whether a terminal might be fired and use a regular QProcess in that case. That would be much easier to implement if QGuiProcess inherits QProcess, no?

> It's rather surprising that the events are not queued until the app processes them.

That may just be how AppleScript implements the feature, but it can also be that the applications I tried this with (Qt apps...) simply discard events until they're all set up.

R.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osxlaunch.m
Type: text/x-objcsrc
Size: 5459 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160105/617d2524/attachment-0001.bin>