<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/119497/">https://git.reviewboard.kde.org/r/119497/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On July 27th, 2014, 1:32 p.m. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line118" style="color: black; font-weight: bold; text-decoration: underline;">kinit/kinit.cpp</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">static KComponentData *s_instance = 0;</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#e9eaa8" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2">118</font></th>
<td bgcolor="#fdfebc" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="cp">#elif defined(Q_<span class="hl">W</span>S_MAC<span class="hl">X</span>)</span></pre></td>
<th bgcolor="#e9eaa8" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">118</font></th>
<td bgcolor="#fdfebc" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="cp">#elif defined(Q_<span class="hl">O</span>S_MAC)</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">this looks fishy, because this should be related to the Window System, not the OS (ie. if you're running X11 on Darwin)</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Proper check would likely be Q_WS_MAC (though ultimately Q_WS disappeared with Qt5 anyway)</p></pre>
</blockquote>
<p>On July 27th, 2014, 2:13 p.m. CEST, <b>RJVB Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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?</p></pre>
</blockquote>
<p>On July 27th, 2014, 2:23 p.m. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This has nothing to do with the graphicssystem (which was set default to raster with 4.8) - the windowsystem is still X11</p></pre>
</blockquote>
<p>On July 27th, 2014, 3:11 p.m. CEST, <b>RJVB Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">On OS X? Are you kidding me?</p></pre>
</blockquote>
<p>On July 27th, 2014, 3:13 p.m. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">No, but I guess we're talking past each other a bit ;-)</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">So, you're actually saying Qt4 can no longer be built for a Darwin/X11 combination (since 4.4)?</p></pre>
</blockquote>
<p>On July 27th, 2014, 4:20 p.m. CEST, <b>RJVB Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I probably should have made explicit that I was talking about OS X, not consider it obvious given the context of this RR O:-)</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
</blockquote>
<p>On July 28th, 2014, 1:37 a.m. CEST, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
</blockquote>
<p>On July 28th, 2014, 2:23 a.m. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This change is meant to be forward compatible with Qt 5.</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">It's likely not.<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
You'll rather have to check for QGuiApplication::platformName() there (at runtime)</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
a) apparently Q_OS_MAC atm. implies Q_WS_MAC since building for X11 on Darwin is claimed to fail<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
b) X11 and OSX walk together here anyway</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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?</p></pre>
</blockquote>
<p>On July 28th, 2014, 4:02 a.m. CEST, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">"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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">$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).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.)</p></pre>
<br />
<p>- RJVB</p>
<br />
<p>On July 27th, 2014, 11:15 a.m. CEST, Ian Wadham wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
<div>Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.</div>
<div>By Ian Wadham.</div>
<p style="color: grey;"><i>Updated July 27, 2014, 11:15 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kdelibs
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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?"</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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...</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">In this review we have two portability problems:</p>
<ol style="padding: 0;text-rendering: inherit;margin: 0 0 0 2em;line-height: inherit;white-space: normal;">
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
</li>
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
</li>
</ol>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This "deafness" of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment.</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports:<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
Warning: connect() failed: : No such file or directory</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kdeui/util/kcrash.cpp <span style="color: grey">(45eb46b)</span></li>
<li>kinit/kinit.cpp <span style="color: grey">(e41845a)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/119497/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>