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 <[email protected]>: > 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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
