[KDE/Mac] of dbus and remote logins

[Ian Wadham]

Hi René,

On 22/11/2014, at 10:19 PM, René J.V. Bertin wrote:
> On Saturday November 22 2014 21:37:08 Ian Wadham wrote:
>>> So how exactly does this work?
>> 
>> You mean it -does- work and you don't know why? Or do you mean how is it -supposed- to work?
> 
> I mean, how does the normal dbus magic work on OS X, locally of course. It does work, but I'd like to have a better understanding.

Start here: http://qt-project.org/doc/qt-4.8/qtdbus.html
or here: http://qt-project.org/doc/qt-4.8/intro-to-dbus.html

I have not ever used DBus myself, but did once grapple briefly with the
semantics of it in the following pieces of KDE code:
    kdelibs/kinit/klauncher_main.cpp
    kdelibs/kinit/klauncher.cpp

AFAIK DBus is almost always used locally in KDE, i.e. to communicate
between processes (or apps) running in the same machine.  Also a common
usage is via QDBusConnection::sessionBus().xxx(…) or
QDBusConnection::systemBus().xxx(…), which operate on either the standard
Session Bus or the System Bus, set up by Qt, though you can set up your own
busses if you want to live dangerously, as I am sure you will… ;-)

DBus is a higher-level and cross-platform re-implemention of original UNIX
facilities such as inter-process communication (IPC), remote procedure calls
(RPC), semaphores, sockets, etc. which I used to know and love…  FAIK it
uses sockets or something internally and it appears to be implemented as
a daemon that acts as a "telephone exchange", perhaps inspired by the
PDP-11 Unibus.  On MacPorts and OS X it runs independently of KDE and
Qt, via a thing called "launchctl", which I wot not of… :-(

One other thing, in the Qt doco, I think "remote" means "in another process or
app, which is usually in the same machine but could be in another machine,
possibly on the Internet somewhere"...

>> IIRC, the $DISPLAY value was used for a socket to start a different kdeinit4 session on a
>> remote login, but I am not so sure if it relates to your current case.
> 
> I think that's what happens on Linux. Or rather, that's what's supposed to happen when you create the session dbus manually.
> But evidently the $DISPLAY variable isn't used on OS X (or at least I hope it isn't).

$DISPLAY has nothing to do with DBus: and I don't know if it has anything to
do with the "session" DBus in Qt or whether that DBus has anything at all
to do with KDE "session" or "login session" or any other kind of session.

$DISPLAY is (still) used by KDE (kdeinit4 and friends) to add to a pseudo-file
name they all use to name a (local) UNIX (not network) socket.  Lacking any
kind of authoritative advice, I never changed that, but I think it should be changed
to "" (empty string) wherever it is used on OS X.  This use of a socket is probably
about 15 years old, long pre-dating DBus and its KDE predecessor called DCOP.
Perhaps it should be changed to use DBus in KF5, but that's none of my business.

>>> It's not like `launchctl load org.freedesktop.dbus-session.plist` can set an env. variable in the shell that calls it, even less in other shells running at that time. So how come a KDE application launched over a remote session doesn't simply connect to the session dbus running in the local session?

AFAICT, and there is not much explicit mention of it in the QDBus doco, "remote"
QDBus messages (to another machine) are possible, but there would have to be
a co-operating process at the other end, i.e. an app or process that does a hand
shake with your app or process.  Perhaps each would have its own session DBus
at its own end…

Maybe there are ready-made apps or processes or library classes to help with
this "remote" usage.

>> Is this something else that does not work in KDE 4 in OS X?  Maybe ask about it in kde-devel?
> 
> Getting remote dbus sessions to work is pointless on OS X as you well know: Qt4-mac cannot do
> remote displaying.

If you have remote co-operating processes, surely you can do almost anything…

And how about https://www.apple.com/au/remotedesktop/
or https://www.apple.com/au/remotedesktop/remoteassistance.html
or various commercial competitors (Google "Apple OS X remote support").

> It's probably also not a good idea to let KDE applications launched remotely connect
> to the local session dbus (and thus[?] display locally), as a general rule of thumb at least.

I don't think the session DBus is a display mechanism, merely a messaging mechanism.
What the receiver does with the message is a SMOP (small matter of programming)… :-)

> My question is why they don't. IOW, how does the software determine what dbus to connect to.
> AFAIK on Linux you can indeed get the system to launch a KDE app from an ssh session onto
> the local Xserver without complaints about the session dbus by setting $DISPLAY=:0.0 or
> whatever the X server's address is.

Isn't ssh yet another separate issue?  Though it too, I suppose, has "sessions".

> I highly doubt the regulars on kde-devel know/care a lot about this kind of OS X internals …

But they would know more about QDBus than me… :-)

Cheers, Ian W.