GnomeSession TNG

Problems and Goals

Problems with the current gnome-session:

• Massive code rot. Much of the XSMP core hasn't been touched since GNOME 1.x, and it's really unclear why it does some of the things it does.
• Poor integration between autostart and XSMP
• Too much hardcoded functionality; gnome-session doesn't provide enough extensibility, and so people are forced to hack things into gnome-session when they want to add or modify certain components of the default GNOME session.

The big goals for the rewrite are:

• Isolate the XSMP code as much as possible, and make it possible to replace it with D-Bus over time
• Integrate autostart better

• Add new functionality to autostart (both fdo-standardized and GNOME-specific) to make it so that future changes to the GNOME session can be made without needing any changes to gnome-session itself. (Ideally, the only GNOME-specific aspects of gnome-session will be that (a) it uses gconf to store its own configuration information, and (b) it uses "GNOME" for the desktop environment name for OnlyShowIn/NotShowIn autostart files. Everything else GNOME-specific that is currently done by gnome-session ought to be pushed out to other apps that get started via autostart.)

Now started in the new-gnome-session branch of gnome-session in subversion.

Startup

Startup is controlled by .desktop files. The session manager does not have any hardwired startup apps (except gconfd and dbus-daemon, which it needs for its own purposes). The "default session" is just a directory containing a small number of .desktop files to be autostarted.

In "failsafe" mode, the session manager only reads the desktop files from the default session directory. In normal login mode, it also reads desktop files from the system autostart dirs, the user autostart dir, and possibly a saved session.

If an app has an AutostartCondition key in its .desktop file, the session manager checks its value. (See this xdg-list post.) If the autostart condition is false (eg, it points to a gconf key that is unset or false), the app is removed from the list.

Once it has the final list of applications, the session manager starts them in 5 phases: Initialization, WindowManager, Panel, Desktop, and Applications.

• "Initialization" is low-level stuff like gnome-settings-daemon, at-spi-registryd, that need to be running very early (before any windows are displayed)

  • Apps in this phase can make use of a D-Bus interface to set environment variables in gnome-session's environment. This can be used for things like $GTK_MODULES, $GNOME_KEYRING_SOCKET, etc

• "WindowManager" includes window managers and compositing managers, and anything else that has to be running before any windows are mapped

• "Panel" includes anything that permanently takes up screen real estate (via EWMH struts)

• "Desktop" includes anything that draws on the desktop (eg, nautilus).

• "Applications" is everything else

An application's startup phase is controlled by the X-GNOME-Autostart-Phase key in its .desktop file. If this is not set, it defaults to the Applications phase. Applications in the first 4 phases MUST signal to the session manager when they are up and running (via XSMP); the session manager won't start the next phase until every app in the current phase has indicated that it is ready. Applications in the Applications phase aren't necessarily expected to communicate with the session manager.

For each application in a given phase, the session manager runs its RestartCommand if it has saved XSMP state or its Exec line if not. If the .desktop file indicates that the application supports startup notification, then that will be used when launching the app.

An additional new form of startup notification is also used; if the .desktop file has an AutostartNotify key set to true, the session manager will set the DESKTOP_AUTOSTART_ID environment variable to a valid XSMP client id when starting the app. The app is then expected to use that client ID if it connects via XSMP. (This helps the session manager figure out which autostarted app each XSMP client corresponds to.)

Once every application in the current phase has been started, the session manager will wait for them all to indicate that they are up and running:

• Applications that support startup notification will use that to indicate when they are ready
• XSMP clients can be matched to autostarted apps by a number of means:

  • If they were resumed with a saved state or started with AutostartNotify, we know what client ID they will use

  • If they set the SmProcessID XSMP property, we can try to match that against the PIDs of launched apps

  • If the app uses startup notification, we can find its WM_CLIENT_LEADER window and look at the SM_CLIENT_ID property

• In the "Initialization" phase, an application can just exit with status 0 to indicate that it is done setting up.

• Eventually we time out on badly-behaved apps. However, this shouldn't normally happen, because the badly-behaved apps are likely to be in the Applications phase, and we don't wait for them anyway.

Splash Screen

Having .desktop files lets us show proper icons and localized names for all autostarted apps, rather than only having icons and names for a few hardcoded things listed in gnome-session itself (105557). Also, we can use startup notification on the autostarted apps to have a better sense of when they are done launching (fixing 74508, Splash screen does not wait for and display everything that loads).

People want to be able to theme the splash screen (57151 and dups). There are bugs in bugzilla about keeping the gdmgreeter background through startup (322056 (fixed >= gdm 2.19.x), 355190). The latter suggests moving the login splash screen from gnome-session to gdm, and showing only a progress bar (where the progress information would come from gnome-session).

The splash screen would be started as part of the Desktop phase, and would disappear at some point during the Applications phase (probably immediately after the last startup app was launched; having it stick around until the last apps signal that they are ready seems like the wrong thing, since the desktop may be usable from the user's point of view long before that.)

Running

• The session manager will process all XSMP and D-BUS session management requests
• It will handle D-Bus requests from the new session-management capplet
  • list startup apps/session apps
  • add/remove/edit/enable/disable startup app
  • save state of single app

• It will restart SmRestartImmediately apps when they exit (unless they're looping).

  • Should there be a .desktop key for this behavior as well?

• If a key specified as some app's AutostartCondition becomes true while the session is already running, the session manager will start that application when it changes.

  • Eg, if /desktop/gnome/remote_access/enabled becomes true, it will start vino-server. If /apps/gnome-screensaver/idle_activation_enabled becomes true, it will start gnome-screensaver. Etc.

  • Currently this sort of thing is handled in various random places:
    • gnome-screensaver is started as needed by gnome-settings-daemon
    • vino-server is started by gnome-session explicitly if it's enabled, and is also started by vino-preferences if the user uses that to enable it during the session. (But it does not get started mid-session if the user uses gconf-editor to enable it.)
    • gnome-volume-manager is started via autostart and exits if it shouldn't be running. As with vino, its capplet starts it up if you use the capplet to enable it, but it doesn't get started if you enable it by other means

  • There may be some apps with an autostart condition where we wouldn't want them to be started mid-session. (Eg, a motd-displaying app.). It seems like the ones we would want to start would all have an SmRestartStyleHint of SmRestartImmediately... so perhaps we need to include that information in the .desktop file as well

  • Should the session manager send an XSMP Die message to conditionally-autostarted apps if their controlling preference becomes false?