In 2006, Dan Winship presented some ideas about the future of session management in GNOME. He wrote the initial code and defined this nice architecture which turns gnome-session into a more generic session management system and makes it easier to eventually replace the current XSMP-based session management with a saner and less cryptic D-Bus-based protocol in the future. On June 2007, he made a code drop on a branch called new-gnome-session and stopped working on that (for various personal reasons).
Since October 2007, I’ve been sparsely working on this new code (with full support from Dan) on my spare time by filling some gaps, fixing bugs, implementing missing features, etc. So, now the code reached a functional state and I’ve just merged the new-gnome-session branch in trunk. Vincent Untz and I will be working on making the new code shine for 2.24.
If you want to know the general ideas around the new gnome-session, read:
http://live.gnome.org/SessionManagement/NewGnomeSession
Most of the design and features described there are already implemented (if not all).
If you want to know what’s still missing and want to help us, read:
http://live.gnome.org/SessionManagement/Todo
The new gnome-session is fully compatible with current session clients (GnomeClient and others) and no code changes are required on existing apps. However, some simple changes are necessary on some basic components that run during the session such as gnome-settings-daemon, gnome-panel, nautilus, metacity, gnome-keyring, etc. I have most of the patches ready and I’ll be filing bugs for each component soon (actually, I’ve made other necessary changes in some modules during the 2.21/2.22 cycle already).
Big thanks to Dan! This important move would not be possible without his support and invaluable efforts.
There’s still a lot to do during this development cycle.
Testing and patches are more than welcome!
Does this make it easier to support multi-seat configs out of the box for distributions like Ubuntu?
Please also consider adding support for things like “preload”. Before each phase of the startup, the list of applications could be passed to some kind of preloader.
That, or consider adding a few new standard tasks to the startup, like preload users theme and icons, etc.
This might help the stuttering and thrashing when cold-starting my desktop. It could also be cool if GDM could start some light preloading after entering my name but before finishing my password?
Yeah, Pete is right.
A smoother start-up (like OS X) has would be really great.
Actually having Panel etc. loading doesn’t look nice.
Looks like that would be possible/is planned.
reallly great :)) thank you
This all sounds like really valuable work guys, nice work.
After reading the NewGnomeSession page it sounds like it’ll pave the way for a far smoother and more flexible session experience. That said, it makes mention of moving the splash screen in to GDM but then states that it’d probably run in the “Applications” level. Surely this is contradictory?
It’d be far better to have the splash screen as part of GDM run in the “Initialization” level and monitor all the other tasks as they start then exit *before* the “Applications” level – since it can’t monitor those.
That way, from an end-user perspective they’d have a smooth transition from GDM to their desktop – which would have loaded all the major components behind GDM.
Compared to the major architectural changes involved, trivial I know, but something worth baring in mind as an end-result that will make a difference to the user experience.
Nicolas: splash-in-GDM is just mentioned as something that people had been talking about, and something that maybe *could* be implemented, whereas the rest of the splash screen discussion is about what we actually *did* implement. At any rate, the splash screen in new-gnome-session is entirely “non-magical”. (It is launched via a .desktop file just like any other startup app, and it figures out what icons to draw by watching startup-notification messages), so it’s very easy to replace it with something else later.
As for what level to run it in, the general idea is that you don’t want to display *anything* new during the “Initialization” and “WindowManager” phases, because many of the things that start in those two phases affect how things are drawn (eg, starting gnome-settings daemon may change the screen resolution, or the default font, or the icon theme). By not creating any windows until at least the “Panel” phase, you ensure that things aren’t going to first be drawn one way, and then immediately afterward be redrawn slightly different.
(Also, the Initialization and WindowManager phases are ideally supposed to be very very quick, such that you don’t care that the splash isn’t visible during them. http://mail.gnome.org/archives/performance-list/2007-April/msg00003.html has some related info. In particular the “things to look at for optimizing this” list.)
If we are going to redo the splash window so that it’s created by gdm (so we can have an even less-redrawy startup), it will have to be written carefully to deal with the fact that the session’s visual environment may be changing out from underneath it