[Usability] SM UI plan

[Havoc Pennington <hp redhat com>]

Hi,

I wrote it down, though I already had it in my head, I promise!
Please comment. This is almost certainly a post-GNOME-2 issue, though,
because "msm" hasn't had any debugging yet, and has several FIXME in
it as well.

Havoc

SM UI design
===

The session manager's job is to track currently running application
instances, and their instance-specific state. It requires applications
that are compliant with the session management protocol in order to
work.

In GNOME, the session manager also handles the splash screen on
startup, and the logout dialog on logout.

Overview
===

A "session" is a collection of saved application instances. For
example, it could contain a window manager, the panel, Nautilus, two
xclocks, and some gnome-terminals.

The SM supports "named sessions." This just means that it can save
more than one session, and each one is referred to by a name. So the
user might have sessions for home and for work stored on their laptop,
for example, and choose the right one depending on where they are.

The UI for named sessions is entirely handled by gdm or equivalent,
however; once the SM starts, it only knows about one session, which is
the "current session." So there's no discussion in this document of
what the UI for named sessions should look like.

The currently open apps can be saved as the content of a session at
any time by any application that makes a standard save request to the
session manager. We can thus have a Save Session button or menu item
anywhere we like. It's also possible to continuously autosave the
session, but I think this is bad.

My suggestion would be that there is a Save Session checkbox in the
logout dialog (see below), and a Save Session Now menu item in the
panel menus (I don't have the URL for the menu proposal there to see
if we already have it). 

Question: where should Save Session be located in the user interface;
menus? specifically what part of the menus? a button?

General guidelines
===

In error messages and such, the session manager always refers to
"applications" rather than "clients."

Login
===

On login, the SM displays progress in some way as applications are
launched. For example, currently we provide a splash screen with
text/icons showing which app we're currently launching.

There are various nice UI tweaks, such as running the window manager
first to avoid ugliness as apps come up without window borders.

It would be nice to have configurable/pluggable launch effects, so
that people can at minimum replace the splash screen without a code
patch. But it might also be fun if people could write different goofy
effects.

Themeing is pretty harmless here; as long as we show progress somehow
and look attractive, things are fine.

Login error handling
===

After attempting to launch all saved app instances, the SM collects a
list of all failed lauches, and displays them in a dialog. Here is a
screenshot of my current dialog:

  http://www106.pair.com/rhp/login-error.png

The list box should probably be behind a Details button or disclosure
triangle.

If the SM fails to load the session at all (rather than specific apps
failing to run), it displays an error dialog that offers recovery
options. Here is the code showing what I intend to do about these
kinds of error.

  
  switch (reason)
    {
    case MSM_SESSION_FAILURE_OPENING_FILE:
      message = g_strdup_printf (_("Could not open the session \"%s.\""),
                                 session->name);
      /* FIXME recovery options:
       *  - give up and exit; something pathological is going on
       *  - choose another session?
       *  - use default session in read-only mode?
       *  - open xterm to repair the problem, then try again (experts only)
       */
      break;
      
    case MSM_SESSION_FAILURE_LOCKING:
      message = g_strdup_printf (_("You are already logged in elsewhere, using the session \"%s.\" You can only use a session from one location at a time."),
                                 session->name);
      /* FIXME recovery options:
       *  - log in anyhow, with possible weirdness
       *  - try again (after logging out the other session)
       *  - choose another session
       *  - open xterm to repair the problem, then try again (experts only)
       */
      break;
      
    case MSM_SESSION_FAILURE_BAD_FILE:
      message = g_strdup_printf (_("The session file for session \"%s\" appears to be invalid or corrupted."),
                                 session->name);
      /* FIXME recovery options:
       *  - revert session to defaults
       *  - choose another session
       *  - open xterm to repair the problem, then try again (experts only)
       */
      break;
      
    case MSM_SESSION_FAILURE_EMPTY:
      message = g_strdup_printf (_("The session \"%s\" contains no applications."),
                                 session->name);
      /* FIXME recovery options:
       *  - put default applications in the session
       *  - choose another session
       *  - open xterm to repair the problem, then try again (experts only)
       */
      break;
    }
  
A problem we should consider addressing: what if you accidentally lose
Nautilus, the panel, or other key components from your session?  My
proposal here is to extend the SM specification with a special hint,
_GnomeDesktopFeatureHint, where the desktop feature an app provides
can be things like "window manager" or "file manager", and may include
multiple types.  Then, if the SM launches all apps and discovers that
a key app is missing - say, you have no window manager - it will offer
to run an application of that type.


Logout
===

On logout, the GUI will be very similar to the current one; we have
several tasks:

 - confirm desire to log out
 - give options to shut down or reboot 
 - give option to save session

Elliot Lee has suggested the refinement that instead of radio buttons
for shutdown/reboot/logout, we simply have dialog buttons with those
labels.

If "save session" is checked in the logout dialog, we save the session
just before logging out.

We can't really theme the logout effect as easily as the login splash
screen effect, because there are messy technical issues (grabbing the
server to keep the user from clicking on any apps). So most likely
that won't be themeable at least for now.

Saving the Session
===

At the user's request, we can save a snapshot of current application
instances under the current session name. If anything goes wrong, we 
display a dialog indicating which applications were not successfully
saved.

The session manager only knows about applications that support the SM
protocol; other applications can't be saved. Because this will no
doubt confuse users, we need to fix apps that can't be saved. In order
to make that practical, we need users to blame the right person when
apps fail to save!

To that end, when the session is saved, if one or more currently-open
windows belong to apps that don't support session management, the SM
will open a dialog listing those applications and explaining the
issue - 
  "The following windows belong to applications that do not support 
   session management. As a result, these applications will not be
   restarted automatically - you will have to open them yourself 
   next time you log in."

   [list box with names of non-SM windows]

                            [Close]

This could be done by the SM using libwnck; however it might be easier
to do it in the window manager.

Dealing with broken clients
===

There are two cases of broken clients we want to deal with. One is
clients that are locked up or not responding; for those we offer the
following dialog:

  "Application 'foo' is not responding; it may be busy or broken. Would
   you like to keep waiting for it to respond, or ignore it for now?"

                   [Keep waiting] [Ignore it]


'foo' is sadly the binary name of the app, rather than the
user-visible name from its .desktop file, but for now I haven't come
up with a solution to that.

The second case of a broken client is one that keeps respawning in a
loop, such as the panel. Here is the dialog for that:

 "The application 'foo' has been restarted several times in the last
  few seconds, but crashed or exited each time. What do you want to do
  with this application?"

                 [Keep trying] [Never try again] [Stop trying for now]

I won't explain what those buttons do, see if you can guess. ;-) I'm
quite sure no one can, but I still don't know what else to write.

An issue with broken apps
===

Unfortunately, libgnomeui automatically connects clients to the
session manager. The problem with this is that even if the app
developer hasn't done any work to support SM, the session manager
still thinks the app supports SM.

The problem: if an app claims to support SM, then it _must_ restore
the same number of windows it had open when the session was saved
(with the exception of dialogs, if we make that exception in the WM,
and the app has properly marked dialogs as dialogs so the WM can
distinguish).

If the app has 3 windows on save, and only 1 window reopens next time,
then the window manager will get confused; the next 2 windows that the
user opens will be treated as saved windows, and restored to their
previous size, position, and desktop. If you've ever seen Sawfish
resize a Mozilla dialog to full-screen, that is caused by this
problem. (Though it's a Sawfish bug, not a Mozilla bug, since Mozilla
does not support SM and doesn't claim to.)

We can try to work around this by having the window manager never
restore window sizes/desktops/positions after it's been running for
some specific length of time. However, this is unreliable, obviously;
if login takes too long, the WM will fail to restore some
properly-saved windows, and if login doesn't take long enough, the
problem with improper position-restoring will still occur.