Re: [Usability] SM UI plan

[Havoc Pennington <hp redhat com>]

Gregory Merchan <merchan baton phys lsu edu> writes: 
> A UI for GNOME sessions does not belong in GDM because the user's chosen
> environment may not be GNOME. (That GDM is the display manager may be
> a choice of the system administrator and not the user.)

If the UI is a dialog after you log in asking which session, then it
can be done in the SM. If the UI is what I would like more (choosing
the session in gdm greeter window), it has to be in gdm.

> There is a source of confusion here. GDM handles PAM sessions which are 
> distinct from X sessions.

It doesn't handle PAM sessions, just "GDM sessions" - the sessions GDM
has (GNOME, KDE, etc.) are purely a GDM feature, they don't have
anything to do with any specs. These sessions are just a way to choose
among various bash scripts.

You're right there's a terminology issue, we can't have two different
things called session.

> On the other hand, I think the session manager may be designed as
> transparent to the user; in which case there is no need to refer to
> GNOME sessions and so PAM can keep the name.

I don't agree we should have a transparent SM (I assume that would
mean constantly autosaving the session). I think most people prefer to
manually save session. This is only visible to the user as a single
checkbox in the logout dialog; it need not even mention sessions, just
say "save open applications for next time" or something.
 
> I think we can do better than this and make session management
> transparent.

While I'm willing to be shown empirical evidence, it isn't what I want
in my desktop, and when we accidentally turned this on during a recent
Red Hat beta cycle, we got a lot of complaints. So I'm doubtful that
it's what people want.
 
> A selection manager (ICCCM 2.8) is probably the correct way to handle
> desktop features. An X client might intern DESKTOP_MANAGER for keeping track
> of desktop features. (The same client, or another, might intern 
> APPLICATION_MANAGER or some such thing for handling application launch 
> feedback and limiting applications to run once; I've only an inkling of an
> idea how this might work and will need time to develop that idea for draft.)

This is probably right for maintaining uniqueness of various desktop
pieces (I've proposed it on xdg-list already I think), but an SM
property would be much more convenient if you want the SM to warn
about missing components.
 
> > Saving the Session
> > ===
> 
> If it is done, please use libwnck or include the session management features
> in the xdg wm-spec. (I.e., use libwnck.)

Assume you're referring to the window manager warning about non-SM
apps. libwnck isn't for window managers. It could be used by the SM to
do this, yes, but no wm-spec extensions are needed in order to do that
AFAIK.

> >                  [Keep trying] [Never try again] [Stop trying for now]
> 
> By the time this is presented, hasn't it already stopped trying temporarily?

Sure, it stops while asking the question, but that's a
pedantic/literal point, I don't think it makes any difference.

> 
> > An issue with broken apps
> > ===
> 
> WM_CLASS is supposed to be a NUL separated pair of strings with instance 
> and class names (ICCCM 4.1.2.5) As I understand it, Gtk+ handles this 
> automatically, so if that is working correctly we should only expect this
> problem with non-Gtk+ apps. Or perhaps libgnomeui needs to do more?

App authors would need to set the instance names and roles explicitly,
GTK/libgnomeui have no way of doing this automatically. So the problem
still exists. Even if you set the name/role, you can normally have
more than one window with the same class/name/role, if the windows are
interchangeable.

So the fact remains that apps should only connect to the SM if they
support session management correctly.

Havoc