Review Request 126161: OS X housekeeping

[René J.V. Bertin]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126161/#review96665
-----------------------------------------------------------



There is one general question that remains: wouldn't it be possible to rewrite the client-side in such a way that applications do not go out over a socket to contact an external klauncher, but rather do what kdeinit5+klauncher are now patched to do directly themselves? Now that the shared library caching feature has been excluded and services are exec'ed it seems that no longer needs to be done by an external server process.

This would probably solve a lot of issues I hear of from users doing standalone app bundle builds, and it should certainly solve the chicken-and-egg question who should install and run kdeinit5.

- René J.V. Bertin


On June 18, 2016, 11 a.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126161/
> -----------------------------------------------------------
> 
> (Updated June 18, 2016, 11 a.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 ae619f7 
>   src/kdeinit/kinit.h PRE-CREATION 
>   src/kdeinit/kinit.cpp 4f6d894 
>   src/kdeinit/kinit_mac.h PRE-CREATION 
>   src/kdeinit/kinit_mac.mm PRE-CREATION 
>   src/klauncher/CMakeLists.txt a8e6c3e 
>   src/klauncher/klauncher.h 92f57fa 
>   src/klauncher/klauncher.cpp baa5649 
>   src/klauncher/klauncher_main.cpp 710c889 
>   src/start_kdeinit/CMakeLists.txt 46d6cb3 
>   src/wrapper.cpp 9cb0a71 
> 
> Diff: https://git.reviewboard.kde.org/r/126161/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.9.5 (and Linux) with Qt 5.5.1-5.6.1 and KF5rameworks 5.16.0-5.22.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.
> 
> 
> File Attachments
> ----------------
> 
> example launchd plist for auto-starting kdeinit5
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/06/18/13a37e04-a7d1-46ac-8782-54a46f06779e__org.macports.kdeinit5.plist
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160618/2f9156d7/attachment.html>