Re: [Usability] SM UI plan

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Oct 18, 2001 at 09:38:05PM -0400, Havoc Pennington wrote:
> 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.

How would the session be chosen in the greeter window without disclosing
information to an unauthenticated user?

> > 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.

Youch, I missed this. I'll have to read the spec; I'd just read some man
pages and thought these were the same. (I'll beat myself severely for this
error after my exam.)

> 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.

I hope constant autosave wouldn't be necessary. Part of what I mean by
transparency is that the user never has to save the session; if the user
does nothing directly affecting the session, then what he has when he logs
in is exactly what he had when he last logged out - modulo any thing which
occured between requesting a log out and the actual log out, such as saving
files from application shutdown prompts.

Was enabling this the cause of the complaints?

(The other part of what I mean is the interface to saved sessions,
 be they location dependent or otherwise. I think the OS/2 'work area',
 or something like it, may be a way to do this, but I'm still working
 on the idea.)

> > 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.

Point of pedantry. Whose convenience and at what cost?

> > > 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.

Sorry, snipped too much there. I was referring to:
> This could be done by the SM using libwnck; however it might be easier
> to do it in the window manager.

I don't know how we'd do this in a friendly manner without adding to wm-spec
and placing responsibilities of the session manager into that seems anathema.
I was just casting my vote for the SM using libwnck and against doing it in
the window manager.

> > >                  [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.

I don't recall if I had a point here or was just checking. :-/
If I had a point, it might have been "Why tell the computer to do what
it has already done?" But I guess that's the most sensible way to dismiss
the dialog if that is what's wanted. I hope I was just checking.

> > > 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.

Okay.


If there are or are to be guidelines on what is a GNOME application,
I'd like them to include conformance to ICCCM and wm-spec, and SM support.


Cheers and Thanks,
Greg Merchan