[KDE/Mac] Aligning the sockets in kdeinit5 and friends on OS X
jpwhiting at kde.org
Mon Feb 2 20:31:10 UTC 2015
On Sun, Feb 1, 2015 at 9:24 PM, Ian Wadham <iandw.au at gmail.com> wrote:
> 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.
> socket has to have a file path and all the usages of the socket have to
> on that path name, otherwise the communication will fail and things that
> 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
> "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
> "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
> 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
> namely in:
> @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
> 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
> could be improved.
> @Jeremy: If/when they are looking good, please can you give them a quick
> 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.
Yes, I can do that. I may need a reminder though. TBH I wonder if these
issues should be put into bugs.kde.org and tracked there with the kde-mac
list as cc so we can make sure we cover/fix all the issues that there are.
Another issue I found the other day and just took a quick glance in the
sources to find what's going on:
https://bugs.kde.org/show_bug.cgi?id=343707 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
> 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.
> @David: Some last questions. Why does kinit.cpp use an indirect method
> 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
> using identical code? And could that be implemented by using a macro or an
> include file, rather than cloning code?
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-mac