I may not understand something, but how does it work when I have things
like at-spi2-registryd running on my session? I cannot start one local
and one remote gui session, for example? Of course I mean the user bus.
W dniu 19.08.2015 o 18:13, Simon McVittie pisze:
On 19/08/15 14:12, Mantas Mikulėnas wrote:
sd-bus has better performance and native
kdbus support (and a better API than e.g. dbus-glib), but if you're
writing programs in GTK or Qt or EFL, then you'll still want GDBus or
QtDBus or Eldbus.
To clarify, *everything* has a better API than dbus-glib. libdbus, the
low-level reference implementation that is described as painful by its
own documentation, is better than dbus-glib. Please don't use dbus-glib.
If you don't care about portability beyond Linux, sd-bus is essentially
a better libdbus; if you do care about portability beyond Linux, sd-bus
is unsuitable.
The current devel branch (1.9.20) of dbus-daemon installs the
--user units dbus.socket and dbus.service necessary for this.
It only does that if you configure with --enable-user-session. It is
currently opt-in, because it changes the semantics of how the OS is put
together, and some people seem to feel very strongly about the
historical per-login-session buses. I might swap the user bus from
opt-in to opt-out in 1.11 or 1.13 or something. On Debian and its
derivatives, installing the dbus-user-session package has the same
effect as --enable-user-session (and I'd encourage other general-purpose
distributions to use similar packaging).
dbus 1.9.20 is about to become dbus 1.10.0 with only trivial changes, so
a stable branch with optional user-bus support is (finally) around the
corner.
The user bus address is
... tried by default in libdbus 1.9, GLib 2.45, and sd-bus; so you don't
need to set DBUS_SESSION_BUS_ADDRESS at all, unless you need
compatibility with older versions, or reimplementations like dbus-sharp.
(Technically the same can be done with dbus 1.8.x as well, but AFAIK the
developers do not approve.)
We don't add features in stable-branches, particularly features that
change semantics, so libdbus 1.8.x does not have the necessary code
changes to make the right things for a user-bus happen by default. You
can backport them, at your own risk; or you can just parachute in the
dbus.socket and dbus.service files and not make the code changes, but
then setting DBUS_SESSION_BUS_ADDRESS appropriately is your responsibility.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel