> On April 10, 2016, 10:31 a.m., David Faure wrote:
> > src/klauncher/klauncher_main.cpp, line 152
> > <https://git.reviewboard.kde.org/r/126161/diff/5/?file=455687#file455687line152>
> >
> >     I'm curious, what's the difference between Q_OS_DARWIN and Q_OS_OSX?

Q_OS_DARWIN incorporates all Darwin versions: OS X, iOS but also all of the 
free versions. It's a good thing they're dead in the water because they 
typically use(d) X11.


> On April 10, 2016, 10:31 a.m., David Faure wrote:
> > src/wrapper.cpp, line 63
> > <https://git.reviewboard.kde.org/r/126161/diff/5/?file=455689#file455689line63>
> >
> >     Does qgetenv(MAC_DISPLAY) really do anything sensible on OSX? I assume 
> > this doesn't exist, right?
> >     
> >     It seems to me that generate_socket_name should just assemble the 
> > socket name differently on Mac (and Windows), no?

AFAIK, `MAC_DISPLAY` was just a variable that wasn't supposed to be defined. 
Its only merit was that it allowed a single user to have multiple klauncher 
sockets ... but I doubt that'd ever be relevant.


- René J.V.


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


On April 6, 2016, 7:16 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 April 6, 2016, 7:16 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 ae619f7 
>   src/kdeinit/kinit.cpp ca18603 
>   src/kdeinit/kinit_mac.mm PRE-CREATION 
>   src/klauncher/CMakeLists.txt a8e6c3e 
>   src/klauncher/klauncher.h 53c0803 
>   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 with Qt 5.5.1 and KF5rameworks 5.16.0 as well as Qt 5.6 and 
> 5.20.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

Reply via email to