[KDE/Mac] klauncher & .desktop Execs

[René J.V. Bertin]

On Friday December 25 2015 12:34:08 René J.V. Bertin wrote:

> With the proper changes (still assessing them) that should work on OS X too, no? With the USE_KPROCESS_FOR_KIOSLAVES/QProcess::start I had to jump to a number of hoops and resort to calling the commandline AppleScript interpreter (osascript) to ensure that the launched process is started in front of the calling process. Not easy, as AppleScript isn't really designed for this so I also had to subclass QProcess to launch osascript in detached fashion and set a kill timer to get rid of it should it not complete within a reasonable time. Since kinit will use ObjC++ in my proposed patch it should be possible to achieve the same thing (process opens in front) directly using an appropriate API (AppKit).
> 
> I'll queue testing this on my todolist.

Aaargghh ...

It turns out that [NSApp activateIgnoringOtherApps:YES] has no effect between a fork and an exec (i.e. in kinit::launch) unless I call a forbidden function first. For some reason it is also not possible to use /usr/bin/open as a proxy. More precisely it will fail when the application to be launched is "not an application", i.e. it's a shell script.
Annoyingly the exact same command that fails via execvp() succeeds from the command line ...
It's quite likely that this whole endeavour was bound to fail from the onset because  I doubt that /usr/bin/open preserves the filedescriptor or supports whatever mechanism kinit::launch() uses in the parent process to know that the child launched successfully.

Now I presume that is really not supposed to be the case by design, but also not impossible (and sometimes damn useful on OS X when something needs to be both in an app bundle and in ${prefix}/bin or libexec).

So what I'd like to do as a last test is this:
- leave the mechanism by which klauncher is started alone, as well as a few others (to be defined)
- for everything else, use the fact that /usr/bin/open will spawn in the background, and call it via QProcess instead of a fork+exec protocol. 

Can I just do that in kinit::launch(), instead of (and before) the fork() call?

R.