On Tue, Jan 28, 2014 at 12:28 PM, Lennart Poettering <mzta...@0pointer.de>wrote:
> On Tue, 28.01.14 09:56, Sriram Ramkrishna (s...@ramkrishna.me) wrote: > > > > 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 every> > > > > So this seems like we are going to continue to use gnome-session in > > order to maintain support for non-systemd operating system. My > > question is, why not at least move everything to systemd --user for > > systemd sessions instead of maintaining gnome-session? That way we > > get the benefits of things like bootchart and have more direct control > > of how GNOME starts? > > gnome-session does a number of things where we don't want to see systemd > get involved with. For example, in .desktop files there are some GNOME > specific settings which allow you to bind it to a specific dconf key, > and I am pretty sure systemd should not hook into that (not because > dconf was bad, but simply because we should try hard to avoid making > systemd a client of the daemons it manages). Also, note that we systemd > Makes sense. Creating any kind of circular logic is just asking for trouble. > we actually are changing the scope of things a bit. While previously > gnome-session would be run inside the original user session and would > then fork everything off directly, also inside the user session, we want > a different layout in a systemd world: instead of having everything run > inside session scope, we want to move things to user scope. Which means > everything is forked off a singleton per-user systemd --user instance > that is shared by all active sessions. Now, to start a service we still > need one component though that continues to run in the session and just > tells the systemd --user instance to spawn gnome-settings-deamon, > gnome-shell and all the other services... We want this one component to > be gnome-session. > This is great implementation detail and it's easier to understand what the end state is going to be. But then again, I haven't talked to the KDE guys about this. I probably > should though. Maybe Ryan, we should do another fdo summit like last > year? What do you say? Maybe organized next to some other European > conference, like LinuxTag or so? > I had asked for some verification and it seems Aaron Seigo has been driving some of this for Plasma, so I think he would be a good person to talk to about it. sri
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
