<div dir="ltr">Ian,<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 1, 2015 at 9:24 PM, Ian Wadham <span dir="ltr"><<a href="mailto:iandw.au@gmail.com" target="_blank">iandw.au@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi guys,<br>
<br>
There are a few places in the Frameworks codebase where a UNIX socket<br>
(as opposed to a network socket) is used to communicate with kdeinit5. That<br>
socket has to have a file path and all the usages of the socket have to agree<br>
on that path name, otherwise the communication will fail and things that should<br>
happen, after the communication, will also fail.<br>
<br>
In Linux, the name has $DISPLAY appended to it, but on Apple OS X,<br>
depending on which version you use (out of several supported by<br>
MacPorts), $DISPLAY may have a UNIX-like value, no value at all<br>
or a variable value assigned by the XQuartz X11 server when it is<br>
needed by X11-based apps.<br>
<br>
Discussion took place last year on <a href="https://git.reviewboard.kde.org/r/119497/" target="_blank">https://git.reviewboard.kde.org/r/119497/</a><br>
"Report crashes of KDE apps in Apple OS X (1) (fix kcrash)"<br>
It indicated that use of $DISPLAY was not necessary on OS X, and David said:<br>
<br>
"The reason we have $DISPLAY in the kdeinit socket name on X11, is to<br>
allow the same user to have more than one graphical session. I don't<br>
mean two full KDE-workspace instances running (they'd overwrite config<br>
files), but it happened to me sometimes that I would use ssh -X from<br>
another machine, then start one app (which wasn't running in the main<br>
session). What happens then is that another kdeinit4 starts, in that<br>
separate session (which has a separate dbus session). So it should all<br>
be separate from the main session, hence $DISPLAY.<br>
<br>
"AFAIK this use case doesn't apply to Mac, so it would be ok to have an<br>
empty string in there."<br>
<br>
One problem at that time on KDE 4 and now on Frameworks is that pieces<br>
of code that use kdeinit5's socket do not agree, on Apple OS X, on how to<br>
compute the associated file path, so communication breaks down.<br>
<br>
The search <a href="http://lxr.kde.org/search?v=kf5-qt5&_filestring=&_string=kdeinit5_" target="_blank">http://lxr.kde.org/search?v=kf5-qt5&_filestring=&_string=kdeinit5_</a><br>
returns six hits in KF5 on the string "kdeinit5_", which is a fixed part of the<br>
socket's file name. Three hits are not to do with the socket and three are,<br>
namely in:<br>
<br>
frameworks/kcrash/src/kcrash.cpp<br>
frameworks/kinit/src/kdeinit/kinit.cpp<br>
frameworks/kinit/src/wrapper.cpp<br>
<br>
@David: Please can you confirm that these are the *only* relevant hits<br>
and that they will catch all the cases where the socket name is generated.<br>
<br>
Attached are three tentative patches to fix things so that the same name<br>
is generated everywhere in Frameworks on Apple OS X. I am proposing<br>
to use "NODISPLAY", rather than the value of $DISPLAY or $MAC_DISPLAY.<br>
One reason is to make sure wrapper.cpp and kinit.cpp use the same name.<br>
<br>
Otherwise, on KDE 4, the kdeinit4_shutdown executable built from wrapper.c<br>
did not shut down kdenit4 in a controlled fashion on Apple OS X. I am hoping<br>
that my patches, or something similar, will ensure that kdeinit5_shutdown<br>
works correctly on Apple OS X.<br>
<br>
Please have a look at the patches and let me know what you think and how they<br>
could be improved.<br>
<br>
@Jeremy: If/when they are looking good, please can you give them a quick test.<br>
Something like start kdeinit5, crash an app and see if KCrash asks kdeinit5 to<br>
start Dr Konqi and kdeinit5 receives the message. Then see if the command<br>
kdeinit5_shutdown causes kdeinit5 to receive a message on the socket.<br></blockquote><div><br></div><div>Yes, I can do that. I may need a reminder though. TBH I wonder if these issues should be put into <a href="http://bugs.kde.org">bugs.kde.org</a> and tracked there with the kde-mac list as cc so we can make sure we cover/fix all the issues that there are.</div><div><br></div><div>Another issue I found the other day and just took a quick glance in the sources to find what's going on:</div><div><a href="https://bugs.kde.org/show_bug.cgi?id=343707">https://bugs.kde.org/show_bug.cgi?id=343707</a> It seems kdeinit5 is always looking for three specific libraries to load, but their names are linux/unix names in an #ifdef Q_OS_UNIX block. Do we need these libraries and their names just need to be fixed or are they not needed on OS X ? I would think at least the first two there are needed, I'll give that a shot (changing the names it's looking for) and put a patch on reviewboard for that today. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
It is quite possible that Dr Konqi will not start and kdeinit5 will not shut down,<br>
but those are topics for another email. One step at a time. I just want to make<br>
sure we can get the communication happening among kdeinit5 and friends<br>
on Apple OS X.<br>
<br>
Cheers, Ian W.<br>
<br>
P.S.<br>
@David: Some last questions. Why does kinit.cpp use an indirect method called<br>
displayEnvVarName() to look for the socket name's suffix, but both crash.cpp and<br>
wrapper.cpp use a direct method called getDisplay()? Should not all three be<br>
using identical code? And could that be implemented by using a macro or an<br>
include file, rather than cloning code?<br>
<br>
<br><br>
<br><br>
<br>_______________________________________________<br>
<a href="mailto:kde-mac@kde.org">kde-mac@kde.org</a><br>
List Information: <a href="https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac" target="_blank">https://mail.kde.org/mailman/listinfo/kde-mac<br>
KDE/Mac</a> Information: <a href="http://community.kde.org/Mac" target="_blank">http://community.kde.org/Mac</a><br></blockquote></div><br></div></div>