Re: [gdm-list] a few gdm changes

[Brian Cameron <Brian Cameron Sun COM>]

Mike/Ray:

> > > I really appreciate you helping with this.  Did you also add Failsafe
> > > login support.
> > No, I haven't done anything with failsafe.  Mostly I took code that
> > was there already and turned it on.
> >
> > Is failsafe really interesting?  I mean the type of user that can use
> > a failsafe xterm, could just as easily use the text console for the
> > same effect right?
>
> GDM greeters don't only run on machine consoles, and even when they
> are on-console not all consoles provide virtual console switching.  A
> failsafe session can be helpful for people coming in from remote X
> servers (especially in situations where there's zero chance of being
> able to lay your hands on the machine where GDM is running) or working
> on systems that don't have VT/VC capability.

Failsafe is also useful for doing things like upgrading or uninstalling
and then reinstalling software that might affect the running desktop.
I sometimes have bad behavior if I try to uninstall and then reinstall
a GNOME base library, or D-Bus, while running a full GNOME session.

> > For a lot of users, though, a failsafe session
> > wouldn't be useful at all, and a lone terminal is a pretty confusing
> > failsafe anyway.
>
> And for a more sophisticated user, or an unsophisticated user working
> under the direction of a support person on the phone, a failsafe
> session might be extremely useful.

Plus, I think the ability to use Failsafe to fix broken $HOME/.profile
issues is handy.  As Mike points out, VT isn't always available.

> > Even if we do have failsafe, does it make sense to treat it different
> > than other sessions?  Maybe we should just ship a desktop file that we
> > install in /usr/share/xsessions ?  If users of different desktop
> > environments expect different terminals, then maybe it should be up to
> > the individual desktop environments to provides the failsafe sessions?

This could be an option.  Requiring such a desktop file does add one
more thing that could make a Failsafe session unavailable or broken
(if the file is missing, accidently uninstalled or corrupt).  But
adding this one dependency on a desktop file is probably not so bad.

However, there is some special things a Failsafe session should provide
(see below).  Perhaps we could extend the desktop format to specify
that this is a "Failsafe" session.  Then it would do these special
things.

The existing GDM does the following "special" things for Failsafe:

- Ignores errors from PreSession, PostLogin script.  The old GDM always
  ignores errors from PostSession regardless of Failsafe.  Errors
  from PostSession should also be ignored in failsafe mode, though.
- Avoids trying to build $HOME/.xsession-errors
- Avoids running Xsession, instead just running the terminal program.
- Has some special logic (focus_first_x_window in slave.c) to cause
  the xterm window to get focus.

This helps to make sure that the user can actually log in even if
there are issues with the PreSession/PostSession/PostLogin/Xsession
scripts, or with the user's $HOME/.profile (and related files) since
$HOME/.profile is sourced by Xsession.

> Obviously there are limits to what even a real failsafe can tolerate.
> GDM itself could be damaged to the point where it can't give you even
> a minimal failsafe.

Right.  I think it is probably okay to require a .desktop file, but
the desktop file would need to identify itself as a Failsafe somehow
so GDM would know to treat it in a failsafe way.

> > > Buttons are also nice and a little easier to use than menus, perhaps a
> > > configurable Toolbar where the user can pick which buttons are available
> > > in the toolbar?
> > I'm not this should be configurable.  What does the user gain?  One
> > thing I'd like to avoid is the giant matrix of settings that the
> > current gdmsetup has.
>
> Agreed.  And if there really is a need for customisation at all in this
> area then it seems like this is something that could be handled by
> theming, not by more controls in 'gdmsetup'.

I agree also.  Buttons may be a little more convenient, but I don't
think any added usability is really worth the added complexity.  The
problem with buttons is that they often have associated images which
need to be themed for a11y, etc.

Brian