Review Request 125163: Disable X11,XCB etc. detection on OS X

Wed Sep 23 19:54:19 UTC 2015

> On Sept. 13, 2015, 9:52 a.m., Martin Gräßlin wrote:
> > I'm in favor of the approach as this solves the problem that again and again [1] we have attempts of OSX-specific disabling of X11 in various frameworks and applications.
> > 
> > The big problem on OSX seems to be that one doesn't want suport for X11, as it's not the windowing system. The code we have in our frameworks which is X11 specific performs runtime checks, thus is dead code on OSX anyway. For (to me unknown) reasons X11 gets pulled in during build on OSX though, causing either useless or crashy code to be included. Thus there are attempts to patch the frameworks instead of just fixing the cmake build command.
> > 
> > I understand that it's a behavior change and thus dangerous. But that's the same for each framework which gets "fixed" in the way I describe above. In the end from what I understood from our OSX devs: they don't want X11 and it's from their perspective a bug that it gets picked up. To me it sounds like we should really break our rules to provide an overall better product. Thousand micro-edits in the frameworks are more dangerous than the one time explicit break.
> > 
> > For what is worth I suggest that a warning could be printed by CMake, that those modules are not searched for and what's the command to override it.
> > 
> > [1] There is already a huge list of reviews which I blocked because they were just wrong, but there are probably way more frameworks which got "fixed" where I just didn't notice the review.
> 
> Samuel Gaist wrote:
>     Getting X11 in the process is pretty easy: install ffmpeg with macports and you have it in (or at least parts of it).
>     
>     One problem I see about X11 on OS X is that it's not an official or tested platform for Qt and like you said most of the code already disables it at run time in KDE. I don't know the effort (in man power) needed to support it properly. I think that would mean at least having a CI building Qt 5 and running tests for that combo to ensure everything is running fine from a Qt point of view.
>     
>     @martin, can you share that list ? It could help speed things up to build a full KDE on OS X
> 
> Allen Winter wrote:
>     right. I wouldn't object to going even further than this patch: Don't check for X11 on MAC. make sure FOUND_X11 is always FALSE. Just like you wouldn't check for X11 on Windows.
> 
> Martin Gräßlin wrote:
>     > @martin, can you share that list ? It could help speed things up to build a full KDE on OS X
>     
>     sorry, I don't track them and wouldn't know how to find it quickly. In the end I don't think it matters to know those. Specify no X11 and all is fine.
> 
> Alex Merry wrote:
>     Martin: I'm not opposed to the change as such, but as you note, it is potentially dangerous. I just want to get an idea of whether changing the default behaviour like this is likely to cause issues for anyone. Is building Qt-based software with X11 support on OS X a use case anyone really cares about? If so, who, and why?
>     
>     Allen: that's pretty much what this patch is doing.
> 
> René J.V. Bertin wrote:
>     Guys, can you please add the kde-mac group when discussing things that concern OS X?! It's only by accident that I've come across this change.
>     
>     To answer a few open questions: X11 is not at all an unusual environment on the machines of users who are (most?) likely to have an interest in KDE applications (4 or 5 or even 3). Installing port:ffmpeg (= MacPort's ffmpeg port) with the default X11 variant is indeed a way to get it installed, but if others are like me they also use a selection of X11/Gtk/Gnome applications and maybe even run an XQuartz session all the time. I know I'm not even alone in using xterms :)
>     
>     So yes, it's been a recurrent "fight" to get rid of X11-specific code that kept popping up in KDE4 sources and build systems in part because not every KDE developer was bothered keeping clearly platform-specific code inside #ifdefs or separate modules. With KDE4/Qt4 the situation was simple: Qt4 cannot be built for Darwin/X11 anymore since 4.6 or 4.7 .
>     With Qt5's QPA architecture this is possible again, though not officially supported. It is even possible to build just QtBase for xcb and then install only the xcb plugin and its dependencies into the Cocoa build/install, and run applications over X11 (even remotely as long). My own port:qt5-kde (Qt5 port with a number of patches that improve the KDE experience, based on my experience with KDE4) offers a mechanism to do just that.
>     
>     That doesn't mean KDE applications should detect X11/xcb and include code that's specific to that platform. As long as they don't invoke "native" APIs directly for displaying purposes they should benefit from Qt's xcb support if a user wants that. The prospect of being able to open KDevelop remotely on my Linux netbook appeals much more to me than going through VNC, for instance (huge screen size differences).
>     
>     What is the official dogma on using platform-specific code for displaying purposes? Outside of clearly X11-specific contexts like KWin, are developers free to use X11 calls when they prefer them over the Qt equivalents, or are there strong guidelines to avoid that or wrap such sections in #ifdefs?
>     
>     > Is building Qt-based software with X11 support on OS X a use case anyone really cares about? If so, who, and why?
>     
>     In short, yes, me and at least 1 person from Fink. But only as far as a reasonable effort to have Qt-based software that also runs when started with `-platform xcb`.
>     
>     I probably wouldn't mind at all if it were possible to build a full X11-based KDE (4 or 5) desktop to run in a rooted X11 window, meaning you can toggle between an OS X desktop and a KDE desktop (or between a "PC" and a Unix workstation...) with just a keyboard shortcut. But that's just not feasible.

Ah, I didn't think that there might be a mac-specific group to add. I'll bear that in mind for the future.

Ideally, X11-specific code should also be runtime-wrapped in checks for the QPA backend (also for Wayland on Linux). Theoretically, it should be possible to build KDE software with X11 support on a mac that would work in either mode. I'm not exactly sure what the issue with building KCrash on Mac was, but as Samuel Gaist noted, we're short on people who care about X11-on-OS-X and have the time and desire to work on stabilising that support. Given that, defaulting to the "usual" case (of not having X11 support on OS X), which is better tested, seems reasonable.

- Alex

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

On Sept. 15, 2015, 10:50 p.m., Samuel Gaist wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125163/
> -----------------------------------------------------------
> 
> (Updated Sept. 15, 2015, 10:50 p.m.)
> 
> 
> Review request for Extra Cmake Modules.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> -------
> 
> Disable X11,XCB etc. detection on OS X
> 
> 
> Diffs
> -----
> 
>   kde-modules/KDECMakeSettings.cmake 0c997931abee8673ccecc66d122108c6f72bf9b1 
> 
> Diff: https://git.reviewboard.kde.org/r/125163/diff/
> 
> 
> Testing
> -------
> 
> KCrash build on OS X 10.8
> 
> 
> Thanks,
> 
> Samuel Gaist
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20150923/c45039d1/attachment.html>