GnomeSession (DBus based branch)

Contents

GnomeSession (DBus based branch)

Problems and Goals

Problems with the gnome-session <= 2.22:

Relies solely on XSMP for client management
Newer alternative sessions (GDM Greeter, OLPC Sugar) don't want to support XSMP
XSMP operation isn't well creating cross platform SM client abstractions
The way XSMP supports blocking logout and shutdown is problematic
Doesn't have a way for clients to proactively inform the session manager they are busy
Isn't well integrated with suspending power and user-switching
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 (and therefore between apps and desktop files)
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
Don't base design around XSMP lifecycle
Add a native D-Bus SM interface
Provide an adapter interface for legacy XSMP clients
Integrate autostart better
Provide a "inhibit" API for clients to proactively inform the SM that they are busy
Provide an improved logout experience
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 dbus_based branch of gnome-session in subversion.

Relationship to D-Bus Session Bus

With the exception of legacy XSMP clients, the session manager will require that all clients connect to the D-Bus session bus and remain connected until they are finished. Client lifecyle is tracked via session bus names and NameOwnerChanged messages. This model of operation places the session bus at the root of the session and this is consistent with its original design goals. The session bus also has the ability to launch well known application services. So, why do we need a separate session manager? Some reasons include:

Provide an adapter for legacy XSMP clients
Provide a way to stop clients
Start or stop an application based on a GConf key value (for a11y tools etc)
Start/stop applications and services in a specific order
Compute statistics for recently/frequently used applications
Provide logout notification
Provide a way for applications to proactively indicate that they need to block logout, shutdown, switch-user and give a reason why

Basically, the session manager is layered on top of the D-Bus session bus and provides some additional features that may not be desireable to put directly into D-Bus.

Client Lifecycle

1. Launch

The client may be started by the Session Manager via:

Autostart
GConf key conditional start
Restarted after explicit exit or crash

If an application has an AutostartCondition key in its .desktop file, the session manager checks its value. If the autostart condition is false (eg, it points to a GConf key that is unset or false), the app is not launched until the condition becomes true.

The Session Manager will set the DESKTOP_AUTOSTART_ID environment variable to a valid client ID when starting the app. The app is then expected to use that client ID when registering with the session manager. This allows the session manager to figure out which application (desktop file) the client corresponds to. The session manager will wait a while for this client to register itself before giving up.

2. Connect

The client should then connect to the either the D-Bus session bus and potentially register for a well known name. If the client is a legacy XSMP client, then it should connect to Session Manager by using SmcOpenConnection with the value of the environment variable SESSION_MANAGER. If XSMP clients are not supported then the SESSION_MANAGER variable will not be set.

3. Register

The client must explicitly register itself with the session manager. At this time it should specify the client ID that was passed to it with DESKTOP_AUTOSTART_ID if one exists. The registration indicates to the session manager that the application associated with the client has started successfully.

In the case where a startup ID is not available the session manager will attempt to match the client with an application in the autostart database.

4. Run

During this phase the application is operational.

5. QueryEndSession

The client enters this state when the session manager determines a logout is about to take place and asks all clients if they have any reason why it should not take place. The client should communicate this to the session manager. This state will either be cancelled or a transition to EndSession will occur.

The client has one second to respond to this request. If it does not respond then it is assumed that it is not OK to proceed. If any client indicates that it not OK to proceed with logout or any clients have indicated this proactively then the user is presented with a list of these clients and activities and is allowed the option of logging out anyway.

When possible, a flag will be passed with this signal to indicate whether this logout will be forceful or not. A forceful logout will not allow any applications to delay logout for more than TBD seconds. Clients may wish to use this extra information to change behavior.

It should be stressed that, even when not forced, clients should not assume that they will have the ability to block logout or shutdown.

This state may last a certain time (TBD) or until all proactively indicated tasks (aka "inhibitors") have finished.

6. EndSession

This state is used to indicate to the client that it should perform final cleanup before exiting.

The client may not delay this stage more than ten seconds.

7. Unregister

This is usually implicitly done when the client disconnects from the underlying protocol or exits.

8. Termination

The client application quits. If the application desktop file has registered X-GNOME-AutoRestart=true then the application will be automatically restarted when the client exits.

Session Manager Lifecycle

1. Startup

The session manager is in this phase while it performs internal setup and initialization. It will read and process the desktop files for each application in the autostart database. It will assign each of them to a startup phase based on the value of the X-GNOME-Autostart-Phase value in the desktop file. If this value isn't specified it is assume to be in the Applications phase.

In "failsafe" mode, the session manager only reads the desktop files from the default session directory.

2. Initialization

During this phase the session manager starts up core session services. Any service that intends to set up the environment (including setting environment variables) should be run during this phase. This can be used for things like $GTK_MODULES, $GNOME_KEYRING_SOCKET, etc.

In this phase an application can just exit with status 0 to indicate that it is done setting up.

The session manager will wait until every application in the current phase has indicated that it is ready or a maximum of ten seconds.

3. WindowManager

Will start applications that provide window/compositing management. This includes anything else that has to be running before any windows are displayed.

Applications started in this phase MUST register with the session manager when they are up and running. The session manager will wait until every application in the current phase has indicated that it is ready or a maximum of ten seconds.

4. Panel

Will start applications that create _NET_WM_WINDOW_TYPE_PANEL windows. This includes anything that permanently takes up screen real estate (via EWMH struts).

5. Desktop

Will start applications that create _NET_WM_WINDOW_TYPE_DESKTOP windows. This includes anything that draws on the desktop (eg, nautilus).

6. Application

Will start all applications that have not been started in any of the previous phases.

Applications started in this phase SHOULD register with the session manager when they are up and running. The session manager will wait until every application in the current phase has indicated that it is ready or a maximum of ten seconds.

7. Running

Session should be fully prepared for use.

8. QueryEndSession

The session manager enters this phase when it determines a logout is about to take place. It asks all registered clients if they have any reason why it should not take place. The client should then respond with an answer. If the client indicates that it would prefer logout to be blocked it should provide a reason for it. This state will either be explicitly cancelled or a transition to EndSession will occur.

Each client has one second to respond to this request. If it does not respond then it is assumed that it is not OK to proceed. If any client indicates that it not OK to proceed with logout or any clients have indicated this proactively (via inhibiting) then the user is presented with a list of these clients and activities and is allowed the option of logging out anyway.

9. EndSession

The session manager enters this phase when a logout is about to take place. This state is used to indicate to the client that it should perform final cleanup before exit.

This phase lasts ten seconds or until every client has responded, whichever is longer.

10. Exit

The session will terminate. All applications should exit with it.

Associating Applications and Clients

A client is a running instance of an application. The application is launched and a client should register with the session manager. For now, the way we associate Clients with Applications by requiring the Client to register using the DESKTOP_AUTOSTART_ID, if it is available, or the application identifier.

This works reasonably well for applications that are started directly but may not be ideal for D-Bus activated services. The application ID may still work in that case but it may not be ideal. In the future, we may want to support a new type of Service client for this case.

How should an application know what identifier to use?

Good question.

D-Bus API

http://www.gnome.org/~mccann/gnome-session/docs/gnome-session.html

AutostartCondition

AutostartCondition is an extension of the Desktop Application Autostart Specification proposed by Dan Winship: http://lists.freedesktop.org/archives/xdg/2007-January/007436.html

If a key specified as some application's AutostartCondition becomes true while the session is already running, the session manager will start that application when it changes. If the same key becomes false while a client is connected for that application it will be stopped.

Use Cases

Vino Server

Start application when GConf key becomes true
Stop client when GConf key becomes false
Restart application immediately when it exits (except if logging out)

Possible implementation:

key=/desktop/gnome/remote_access/enabled
X-GNOME-AutoRestart=true
Client would also set RestartStyleHint=GSM_CLIENT_RESTART_IMMEDIATELY

Screen Magnifier

Start application when key becomes true
Stop client when key becomes false
Set key to false when client is explicitly quit by the user

Possible implementation:

key=/desktop/gnome/applications/at/screen_magnifier_enabled (proposed)
X-GNOME-AutoRestart=true
Client would initially set RestartStyleHint=GSM_CLIENT_RESTART_IMMEDIATELY
Client would indicate that it is exiting cleanly and the SM would set key to false

Desktop Tour / First login configuration tool

Start application when key becomes true
Stop client when key becomes false
Set key to false when user clicks "Do not show again" checkbox (or similar)