On Tue, 21.01.14 19:49, Giovanni Campagna ([email protected]) wrote:
> > 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... Yeah, it took a while to stabilize but it should just work on Fedora, after making the change from Kay's mail in /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh. > > 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. Well, this seems unnecessary. And app should just check for $DBUS_STARTER_BUS_ADDRESS or $DBUS_STARTER_BUS_TYPE. If that is set it is bus actviated. If it isn't it is not. In the latter case it should pop up a window. > 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. Sure, most of the .desktop files from /etc/xdg/autostart aren't apps but background services. The standard NoDisplay= field should be set for these. I think the current desktop file spec covers this neatly already. > Finally, systemd has a generator for .service files, it hasn't got one > for .desktop files, so why pushing for deprecating .service? Because it appears redundant and complex. And especially with a perspective of sandboxed apps I'd like to minimize contact points between apps and the host to a minimal number. > > 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). Well, but you could get all of this with .desktop files too, if systemd understood them natively. (Not saying that you shouldn't ship native systemd unit files, there are many reasons one might still want to do that, since it opens up so many additional settings...) > > 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... Hmm, do we actually really want XSMP still? This has come up a couple of times already in the past, isn't it time to finally let it go? I'd really prefer if mutter/gnome-shell and gnome-settings-daemon would be forked off systemd. To explain this, a bit more about the bigger picture regarding sessions and seats and the user bus: I'd expect that the display manager (at least in a Wayland world) would be something that is started when the user first logs in and then stays around until he last logs out, grabbing all devices attached to the seats of the sessions of the user as the user logs in and out. i.e. I'd like to see the display manager as a per-user singleton that manages not just one session but everything that pops up for the user it runs under and merges this into one big xinerama-style display. Or in other words: if the same user logs into two local seats he would get a single gnome-shell that spans all seat's displays. (optionally, the user could also move this to "clone" mode, as he already can). As David Hermann just assured me on IRC me something like this is not too hard to make work for both Wayland and X11 actually. Now with that in mind, gnome-shell/mutter/wayland would be started when the first user session is created, and would stay around until it sees that the last session is gone. If we instead ran it as part of a specific user session then it would go away as soon as that one session died, which is less desirable... Lennart -- Lennart Poettering, Red Hat _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
