KDE adoption of D-Bus
hp at redhat.com
Wed Feb 15 09:06:54 PST 2006
On Wed, 2006-02-15 at 16:31 +0100, Thiago Macieira wrote:
> 1) Windows and MacOS X support
> KDE4 (or at least KDE 4 applications) is supposed to run on both of those
> platforms. Has libdbus been ported to those platforms? Does it work? Are
> there known problems?
Tor Lillqvist started on Windows:
It probably has a fair bit of work remaining though. In principle all
UNIX dependencies are in dbus-sysdeps.c but in reality I know some have
leaked out, and also that the dbus-sysdeps.h interface could be modified
to be more platform-neutral. e.g. it could export a handle object that
had a "socket or file" flag, rather than just an integer file
descriptor, which might simplify the Windows port. Or it could have
explicitly separate socket and file functions.
I know people have reported compiling on OS X, it should be pretty easy
to compile with maybe a couple fixes; the hard part is probably
launching the daemon, but that's the same as your point #2 ...
> In other words, is it possible to use D-Bus session if the daemon isn't
> running and DBUS_SESSION_BUS_ADDRESS isn't set?
Right now there is no solution, we have relied on distributions changing
their launch scripts that launch the X server to also launch the dbus
daemon using a command called dbus-launch.
A proposal for how to implement auto-launch:
- modify dbus-launch, or create dbus-launch-x11 - in other
words, there's a separate executable that does the autolaunch,
we don't do this inside the library
- what this executable does:
- grab the X server
- try to read the session's bus daemon off a root window
property on screen 0 (note per-display not per-screen,
so always screen 0)
- if not present, launch the daemon, read the bus address,
and set the property
- ungrab the server
- provide the session bus address to the calling process
- when we use dbus-launch to launch the daemon from the
session init scripts, dbus-launch should set the
root window property as well
- libdbus should use the algorithm:
- if DBUS_SESSION_BUS_ADDRESS is present, use it (much faster)
- else spawn dbus-launch to read the bus address from X11
and possibly start the daemon if needed
- dbus-launch should never *replace* the root window property;
i.e. there's only one daemon per session ever. this is important
for two reasons:
- the daemon is supposed to be the lifecycle "grounding point"
for the session and exiting it is supposed to indicate that
the session is over; its lifetime should match the X server's
- if DBUS_SESSION_BUS_ADDRESS is set, we never look at the
X property, and the env variable can't be changed dynamically.
So allowing daemon restart would be unreliable.
- when dbus-launch does an autostart, it sets up the daemon to
exit along with the X server, just as it does normally in the
session init scripts
This would solve the problem of auto-launch and also solve the problem
of providing the bus address to remote X clients. Though really to make
remote clients work smoothly we need to go one more step and forward the
bus traffic over ssh, at least this way it will work in a no-firewalls
situation (after you turn on tcp for the session bus anyway, it's not on
by default I'm pretty sure).
This problem would need to be solved separately for Windows I would
think, at least for apps that are native to Windows instead of using a
Windows X server; a dbus-launch-win32 might use COM or some other
convenient Windows API to get a singleton object for the user's login
session. In libdbus a simple #ifdef could choose the right dbus-launch
for the platform.
If the above sounds reasonable to you and you have time to hack on it a
bit, would be very welcome.
More information about the dbus