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

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>:

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
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!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]