> On Dec. 25, 2015, 3:42 p.m., René J.V. Bertin wrote: > > src/kdeinit/kinit_mac.mm, lines 662-666 > > <https://git.reviewboard.kde.org/r/126161/diff/4/?file=418469#file418469line662> > > > > I'd love to add `[NSApp activateIgnoringOtherApps:YES]` and/or `[NSApp > > unhide]` here, preceded by `[NSApplication sharedApplication]` so that the > > spawned `executable` appears in front and not behind the windows of the > > "parent" application. > > > > I think that's a very sensible thing to do, but sadly those calls are > > part of (or call into) the SDKs that are off-limits between a `fork()` and > > an `exec()`. > > > > This really makes me reconsider to use a wrapper, because it quickly > > grows old 1) having to wait for an expected application to appear, 2) > > realise it must have opened somewhere in the background and 3) go dig it up. > > > > If only I could be sure that the spawned application is NOT supposed to > > inherit the environment and other context from kdeinit5. In that case I > > could rewrite the command to execute so that it uses LaunchServices ... via > > a proxy that's already available (`/usr/bin/open`). > > > > NB: this may well be why `[NSProcessInfo setProcessName:]` doesn't > > appear to have the intended effect. > > > > So, David, what's worse here — introducing an additional layer or > > putting up with applications that play hide and seek? > > David Faure wrote: > Starting apps via kdeinit is only an optimization. It's perfectly OK to > start apps directly with QProcess instead. So yes, the spawned application is > NOT supposed to inherit the environment from kdeinit5. > > As previously stated, I strongly recommend to avoid the whole > complication of "stuff I can't do between fork and exec" on OSX, but not > using fork and exec at all (wrapper or not), and just starting the other > process directly with QProcess. If that doesn't bring the new app to the > front, maybe that's a QProcess bug or missing feature? If you think about > this as a "pure Qt application developer", such a developer would expect > QProcess to be able to start a GUI app and have it pop up to the front. Maybe > you can write a small test with QProcess, to check if that works out of the > box (maybe all your troubles actually come from the indirection via > kdeinit...) > > René J.V. Bertin wrote: > I will indeed have to have another look at what QProcess does exactly in > qprocess_unix, but a priori it looks a variant on the fork+exec scheme. There > is support for app bundles, but that works by obtaining the bundle executable > and launching it as it if were a regular application. > > The underlying issue is not with Qt, it's something specific to OS X. > Maybe there's a reason for it: it could be a cheap way to avoid stealing > focus from the "parent" process. The app bundle detection could be used to > channel spawning the new process through LaunchServices so that it does open > in the foreground, and that could even be extended to cover symlinks that > point inside an app bundle (i.e. open `foo.app` instead of > `/path/to/foo.app/Contents/MacOS/foo_bundle_exec`). Qt's design choices may > make that impossible though: QProcess's implementatin (notably > `QProcessPrivate::startProcess()`) is quite complex and if it is supposed to > support Posix-style communication between parent and child (including pipes) > then LaunchServices is probably out of the question. I don't think there is > any such assumption in kdeinit, correct? > > I have to come back a bit on the idea of using `/usr/bin/open` : it tends > to use Terminal.app to launch shell scripts and "certain" regular executables > ("BSD utilities" in Mac speak). That's evidently not an option. I do have > wrapper utilities lying around that I hacked together, I'll see if and how I > can refactor relevant code from them into kinit_mac.mm .
FWIW, a contact at Apple just told me "As far as spawning processes in general, please don't use system() or fork()/exec(). Please use the posix_spawn syscall instead as it is much cleaner and has less overhead." I'm not exactly familiar with the API. `QProcess` apparently uses it on QNX, but that appears to be a slightly different implementation. Anyone here know the API? https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/posix_spawn.2.html - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126161/#review90098 ----------------------------------------------------------- On Nov. 26, 2015, 5:20 p.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126161/ > ----------------------------------------------------------- > > (Updated Nov. 26, 2015, 5:20 p.m.) > > > Review request for KDE Software on Mac OS X and KDE Frameworks. > > > Repository: kinit > > > Description > ------- > > This patch addresses several issues with the OS X adaptations: > > -1 replaces the obsolete Q_OS_MAC with Q_OS_OSX > -2 builds the relevant applications `nongui` instead of as app bundles > -3 turns klauncher into an "agent" by setting `LSUIElement` to true > programmatically > -4 ports a patch that has been in MacPorts' `port:kdelibs4` since October > 14th 2009, which prevents a kdeinit crash that is caused by calling exec > after `fork()` in an application that has used non-POSIX APIs and/or calling > those APIs in the exec'ed application. This patch (originally by MacPorts > developers Jeremy Lainé and Jeremy Lavergne) rearranges call order and uses a > proxy application to do the actual exec. > > > Diffs > ----- > > src/kdeinit/CMakeLists.txt f94db71 > src/kdeinit/kdeinit5_proxy.mm PRE-CREATION > src/kdeinit/kinit.cpp a18008a > src/kdeinit/kinit_mac.mm PRE-CREATION > src/klauncher/CMakeLists.txt 746edfa > src/klauncher/klauncher.h e155f72 > src/klauncher/klauncher.cpp 8b3d343 > src/klauncher/klauncher_main.cpp f69aaa5 > src/start_kdeinit/CMakeLists.txt 46d6cb3 > src/wrapper.cpp 95b7ec2 > > Diff: https://git.reviewboard.kde.org/r/126161/diff/ > > > Testing > ------- > > On OS X 10.9.5 with Qt 5.5.1 and KF5rameworks 5.16.0 . With this patch, > starting `kded5` will launch kdeinit5 and klauncher5 as expected, but > `kdeinit5 --kded` does not yet launch `kded5`. This is probably acceptable > for typical KF5 use on OS X (kded5 can be launched as a login item or as a > LaunchAgent) but I will have another look at why the kded isn't started. > > I am not yet able to perform further testing; practice will for instance have > to show whether point 2 above needs revision (apps that need to be installed > as app bundles). > > Similarly it will have to be seen whether point 3 above has any drawbacks. > Applications running as agents do not show up in the Dock or App Switcher. > Thus, klauncher will not be able to "turn itself into" an application that > does have a full GUI presence with my current modification. I don't know if > that's supposed to be possible though. > NB: I have been building the KDE4 klauncher in a way that makes it impossible > to construct a GUI at all, so I'm not expecting issues in KF5 as long as > klauncher's role hasn't evolved too much. > > > Thanks, > > René J.V. Bertin > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
