Re: Hooking up gnome-session with dbus/kdbus/systemd

[Giovanni Campagna <scampa giovanni gmail com>]

I've been working on getting systemd --user to support running my
session too, and I have a few comments from testing.

2014/1/21 Lennart Poettering <mztabzr 0pointer de>:
> Heya,
>
> I am typing this from a GNOME session that actually uses a kdbus user
> bus instead of a dbus-daemon session bus (and also a kdbus system
> bus). With this mail I'd like to start discussion of the changes I'd
> like to propose for GNOME to make this work a bit more smoothly.

Interesting, last I tried I had crashes all over the session, and bus
activation was not working...

> So, the way I'd like this all to work is by simply emphasizing .desktop
> files and bus activation a lot more, without actually emphasizing
> systemd as backend implementation of anything. As both technologies
> (.desktop files and dbus) are universially supported wherever GNOME is
> supported this should be a good approach:
>
> a) I'd like to see native D-Bus ".service" activation files deprecated
>    in dbus. Instead, for the user/session bus, I'd like to see
>    everything moved to .desktop files. Ryan recently extended the
>    .desktop spec for declaring bus names in .desktop files so that
>    applications no longer need to be forked off directly, but can simply
>    be bus activated. I'd like to take this one step further:
>    dbus-daemon/systemd should just read the .desktop files directly, and
>    use this information for maintaining its own activation lists,
>    so that we keep everything at one place, instead of two. Note that
>    currently the .desktop file spec says that either Exec= is honoured
>    or the thing is bus actviated; it would be only a minor addition to
>    say that the bus activation on the bus manager side can actually
>    happen with the Exec= line, too. (As a side note, not directly related
>    to GNOME: on the system level I'd like to see D-Bus ".service"
>    activation files deprecated too, in favour of the native service
>    definition files of the respective init system of the distrbution,
>    regardless whether it might be systemd or Upstart or whatever
>    else). Of course, support for the old .service activation files will
>    be kept for a while for compat.

This won't work, because the Exec line from .service has a different
purpose than the Exec line from .desktop: the first runs the service,
the second activates the application provided by the service (ie, it
opens a window)
For example, gnome-weather's service runs
/usr/share/org.gnome.Weather.Application/org.gnome.Weather.Application,
which is a DBus service that does nothing, while gnome-weather's
desktop runs /usr/bin/gapplication launch
org.gnome.Weather.Application, which sends a message on the bus
telling the service to open a new window and quits.
Similarly, gnome-software's desktop runs /usr/bin/gnome-software,
which is an old style application with a window, no fancy dbus stuff,
while the service runs /usr/bin/gnome-software --gapplication-service,
which just runs idly until it gets a DBus message to open the window.
So we would need a new line, ExecService=, that has the same purpose
as the Exec= key from service files.

Additionally, many session bus services are not applications at all,
and installing a desktop file (which would be picked up by the shell,
increase our caches and confuse our tracking) would be conceptually
wrong them.

Finally, systemd has a generator for .service files, it hasn't got one
for .desktop files, so why pushing for deprecating .service?

> b) The other side of the medal than is that all GNOME programs should
>    ship with .desktop files that include bus activation bits. Currently
>    gnome-weather is the only one that does. I'd like to see the bus
>    activation stuff to be the rule, not the exception.

To be precise, gnome-software, polari, gnome-clocks do as well.
gnome-sound-recorder could be switched easily too (because it uses
gnome-weather's infrastructure).
OTOH, I have a gnome-weather branch that replaces the .service file
with .busname and .service units, which would be nice because I would
get proper starting and stopping, and the ability to be started not
just by busname but also at session start (for a background service
polling NWS advisories).

> c) gnome-session currently has some special .desktop file support that
>    it uses to set up the session and run it (parsing stuff from
>    /etc/xdg/autostart). For that it forks off all
>    processes on its own, and will wait for SIGCHLD to bind the lifecycle
>    of the session to the lifecycle of gnome-settings-daemon +
>    gnome-shell. It also uses that to implement "phases". I'd like to see
>    this minimally changed to watch for the
>    existance of the respective bus names instead, and use normal bus
>    activation to start everything. The phase logic can stay in
>    gnome-session even if gnome-session doesn't fork anything of
>    anymore but uses bus activation for everything. The hookup that these
>    desktop files have with dconf would also stay unmodified.

Well, at least in the interesting cases (gnome-shell and
gnome-settings-daemon), gnome-session hooks the phase logic to an
explicit notification, through XSMP for gnome-shell and through DBus
for gnome-settings-daemon.
The dependencies for the three components are quite complex
(especially as the order is reversed in the X11 and Wayland sessions),
so I'd rather not touch that, and keep "gnome-session + gnome-shell +
gnome-settings-daemon" as a unit.
Everything else could be hooked to bus - except for legacy XSMP
semantics that we need to preserve...

[...]

> Does this make sense? Suggestions? Ideas?

Thanks for doing this!

Giovanni