[KDE/Mac] Aligning the sockets in kdeinit5 and friends on OS X

Ian Wadham iandw.au at gmail.com
Mon Feb 2 04:24:21 UTC 2015


Hi guys,

There are a few places in the Frameworks codebase where a UNIX socket
(as opposed to a network socket) is used to communicate with kdeinit5.  That
socket has to have a file path and all the usages of the socket have to agree
on that path name, otherwise the communication will fail and things that should
happen, after the communication, will also fail.

In Linux, the name has $DISPLAY appended to it, but on Apple OS X,
depending on which version you use (out of several supported by
MacPorts), $DISPLAY may have a UNIX-like value, no value at all
or a variable value assigned by the XQuartz X11 server when it is
needed by X11-based apps.

Discussion took place last year on https://git.reviewboard.kde.org/r/119497/
   "Report crashes of KDE apps in Apple OS X (1) (fix kcrash)"
It indicated that use of $DISPLAY was not necessary on OS X, and David said:

  "The reason we have $DISPLAY in the kdeinit socket name on X11, is to
    allow the same user to have more than one graphical session.  I don't
    mean two full KDE-workspace instances running (they'd overwrite config
    files), but it happened to me sometimes that I would use ssh -X from
    another machine, then start one app (which wasn't running in the main
    session).   What happens then is that another kdeinit4 starts, in that
    separate session (which has a separate dbus session). So it should all
    be separate from the main session, hence $DISPLAY.

   "AFAIK this use case doesn't apply to Mac, so it would be ok to have an
    empty string in there."

One problem at that time on KDE 4 and now on Frameworks is that pieces
of code that use kdeinit5's socket do not agree, on Apple OS X, on how to
compute the associated file path, so communication breaks down.

The search http://lxr.kde.org/search?v=kf5-qt5&_filestring=&_string=kdeinit5_
returns six hits in KF5 on the string "kdeinit5_", which is a fixed part of the
socket's file name.  Three hits are not to do with the socket and three are,
namely in:

    frameworks/kcrash/src/kcrash.cpp
    frameworks/kinit/src/kdeinit/kinit.cpp
    frameworks/kinit/src/wrapper.cpp

@David: Please can you confirm that these are the *only* relevant hits
and that they will catch all the cases where the socket name is generated.

Attached are three tentative patches to fix things so that the same name
is generated everywhere in Frameworks on Apple OS X.  I am proposing
to use "NODISPLAY", rather than the value of $DISPLAY or $MAC_DISPLAY.
One reason is to make sure wrapper.cpp and kinit.cpp use the same name.

Otherwise, on KDE 4, the kdeinit4_shutdown executable built from wrapper.c
did not shut down kdenit4 in a controlled fashion on Apple OS X.  I am hoping
that my patches, or something similar, will ensure that kdeinit5_shutdown
works correctly on Apple OS X.

Please have a look at the patches and let me know what you think and how they
could be improved.

@Jeremy: If/when they are looking good, please can you give them a quick test.
Something like start kdeinit5, crash an app and see if KCrash asks kdeinit5 to
start Dr Konqi and kdeinit5 receives the message.  Then see if the command
kdeinit5_shutdown causes kdeinit5 to receive a message on the socket.

It is quite possible that Dr Konqi will not start and kdeinit5 will not shut down,
but those are topics for another email.  One step at a time.  I just want to make
sure we can get the communication happening among kdeinit5 and friends
on Apple OS X.

Cheers, Ian W.

P.S.
@David: Some last questions.  Why does kinit.cpp use an indirect method called
displayEnvVarName() to look for the socket name's suffix, but both crash.cpp and
wrapper.cpp use a direct method called getDisplay()?  Should not all three be
using identical code?  And could that be implemented by using a macro or an
include file, rather than cloning code?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: GetDisplayInKCrash.patch
Type: application/octet-stream
Size: 396 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150202/1365aff4/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: GetDisplayInKinit.patch
Type: application/octet-stream
Size: 453 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150202/1365aff4/attachment-0001.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: GetDisplayInWrapper.patch
Type: application/octet-stream
Size: 339 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150202/1365aff4/attachment-0002.obj>


More information about the kde-mac mailing list