> On July 27, 2014, 1:32 p.m., Thomas Lübking wrote: > > kinit/kinit.cpp, line 118 > > <https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line118> > > > > this looks fishy, because this should be related to the Window System, > > not the OS (ie. if you're running X11 on Darwin) > > > > Proper check would likely be Q_WS_MAC (though ultimately Q_WS > > disappeared with Qt5 anyway) > > RJVB Bertin wrote: > A bit of a moot point given how Qt4 no longer builds for X11 (since 4.4 I > think) ... or is that supposed to change again with Qt5? > > Thomas Lübking wrote: > This has nothing to do with the graphicssystem (which was set default to > raster with 4.8) - the windowsystem is still X11 > > RJVB Bertin wrote: > On OS X? Are you kidding me? > > Thomas Lübking wrote: > No, but I guess we're talking past each other a bit ;-) > > So, you're actually saying Qt4 can no longer be built for a Darwin/X11 > combination (since 4.4)? > > RJVB Bertin wrote: > I probably should have made explicit that I was talking about OS X, not > consider it obvious given the context of this RR O:-) > > But yes, the latest qt4-X11 version in MacPorts is 4.4.3 . I've tried to > trick the current version into building as if under Linux, but something in > the build process must be too clever for that. Long story short, it appears > to be impossible to build Qt4 for Darwin/X11. > > Ian Wadham wrote: > There is nothing "fishy" about this. As you say, there is no Q_WS in Qt > 5, only Q_OS. And Q_WS_MACX is even more archaic. This change is meant to be > forward compatible with Qt 5. > > It is also meant as a hint to KDE developers to clean up the myriad > references to Q_WS in KDE software when preparing KF 5, if not already done. > > Discussions of X11, Window Systems and raster graphics are irrelevant > here. Qt 4.8 on Mac OS X is called Qt-Mac 4.8 and it works directly with > Apple's Aqua, Core Graphics and COCOA library, using intermixed Objective C > and C++ code, thus giving Qt and KDE applications the same look and feel as > other apps on the Apple OS X desktop, except perhaps when a KFileDialog > appears - like feathers on a dog... :-) The only fly in the ointment is that > Qt_Mac 4.8 did NOT adopt raster graphics as standard (apparently RG was not > ready at the first Qt-Mac 4.8 release time). Hopefully Qt-Mac 5 will remedy > that. > > Thomas Lübking wrote: > > This change is meant to be forward compatible with Qt 5. > > It's likely not. > You'll rather have to check for QGuiApplication::platformName() there (at > runtime) > > I considered it "fishy" because it's "which item doesn't fit" and because > you're actually testing for the wrong item (Darwin, that's like testing for > Linux to use X11 features) what only works because > a) apparently Q_OS_MAC atm. implies Q_WS_MAC since building for X11 on > Darwin is claimed to fail > b) X11 and OSX walk together here anyway > > However, (b) and a comment of yours on bug #337140 , I found googling on > the topic, actually makes me wonder whether $DISPLAY is/was only set for > XQuartz and has no relevance for OSX itself, thus being absent with dropping > XQuartz and therefore absolutely no reliable hook for socket name creation on > OSX? > > Ian Wadham wrote: > "Absolutely". I agree. I have XQuartz installed on my MacBook, but I have > no idea whether that gives rise to $DISPLAY having a value for me or whether > it is supported by OS X 10.7.5 (Lion) itself. AFAIK X11 is used only by some > non-KDE FOSS software apps I have installed, such as Inkscape and Gimp. > > Bear in mind that there has been an evolution of display handling in > successive versions of OS X and that Macports supports versions of OS X > earlier than Lion and up to the most recent release (Mavericks), and that > Qt-Mac supports them too and (in turn) MacPorts supports KDE software on all > of them. The Wikipedia articles on Aqua and XQuartz give some overview of > this evolution. > > $DISPLAY definitely evaluates to the empty string on Mavericks, unless > you happen to have XQuartz installed. Marko found that on his development > setup for KDE CI on Apple OS X (Mavericks). > > FWIW Frameworks' kdeinit/kinit.cpp currently has Q_OS_MACX on line 121. > Maybe somebody ran a script to change all Q_WS to Q_OS, but the "MACX" is not > in the doco for Qt5's QtGlobal. There must be hidden support for it, as there > is for Q_WS_MACX in Qt-Mac 4.8.
Exactly. Whatever is decided, KDE will have to consider that OS X is a Unix without X11, one on which $DISPLAY is indeed undefined. I don't think XQuartz is going anywhere in a foreseeable future but it'd be more future-proof not to depend on its presence at all. And I think that means everything cannot be left to runtime platform determination; code that invokes X11 calls will have to be in/excluded at compile time. Whether or not things are done in a way that allows building for Qt/X11 (if/whenever it becomes possible again) and/or for (Open)Darwin is a different question. (Darwin is the name of the underlying unixy OS, excluding all GUI stuff, a distinction from OS X (macx) that is clearly relevant here.) - RJVB ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review63257 ----------------------------------------------------------- On July 27, 2014, 11:15 a.m., Ian Wadham wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119497/ > ----------------------------------------------------------- > > (Updated July 27, 2014, 11:15 a.m.) > > > Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and > Michael Pyne. > > > Repository: kdelibs > > > Description > ------- > > When a KDE app crashes in Apple OS X, it just disappears from the screen. At > the most, the user is invited to report the crash to Apple. AFAIK this has > been a problem in KDE on Apple OS X for years, leading to frustration with > KDE among Apple users and MacPorts developers and an attitude among KDE > developers of "Why does nobody report the problem(s) on bugs.kde.org?" > > It is my strong belief that the failure to report crashes of KDE apps in > Apple OS X also exists in Frameworks. > > So far I have identified a number of portability bugs in KDE on Apple OS X: 1 > in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are > submitted in this review. Patches for three more are submitted in part 2 of > this review, against kde-runtime. I am still investigating the other two > problems in Dr Konqi - and there could be more than two... > > In this review we have two portability problems: > > 1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors > and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X > library (COCOA) and it crashes if they are closed prematurely. > > 2. The preferred way to start Dr K is via a socket message to kdeinit4, but > that fails in Apple OS X because kdeinit4 is listening with the wrong socket > name. The DISPLAY ID is missing from the end of the name. The fallback is for > KCrash to use fork() and exec(), which works, but could cause Dr K to be > polluted, depending on the nature of the crash. > > This "deafness" of kdeinit4 (and klauncher) could be causing other failures > in KDE software in the Apple OS X environment. > > > Diffs > ----- > > kdeui/util/kcrash.cpp 45eb46b > kinit/kinit.cpp e41845a > > Diff: https://git.reviewboard.kde.org/r/119497/diff/ > > > Testing > ------- > > Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs > via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an > Apple OS X environment and used it to test against the KDE 4.13 branch. I > have been testing with a KDE app that I can crash at will and using stderr > and Apple OS X Console log output to determine the outcome. > > Please note that I am the -only- KDE developer who has this kind of setup, > but I am NOT a KDE core developer. My experience before now has been in KDE > Games. However I used to be a UNIX and database guru before I retired in 1998. > > I NEED HELP from KDE -core- developers to proceed further. These problems > also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks > on Apple OS X. And I am sure there are many more Apple OS X portability > problems in KDE software. > > Without my patches, Dr Konqi is not started and, if it does get past its own > crash, KCrash reports: > KCrash: Attempting to start > /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from > kdeinit > sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0 > Warning: connect() failed: : No such file or directory > > With my patches, Dr Konqi can always be started directly (using fork()) and > it -will- start via kdeinit4 and klauncher but it immediately runs into a > privilege problem with Apple OS X (a problem which I am still investigating). > > I would not have got this far without help from Michael Pyne, Thomas Lübking > and several of the MacPorts developers, as well as the unfailing enthusiasm > and encouragement of my friend Marko Käning. > > > Thanks, > > Ian Wadham > >
