Re: The future of session management in GNOME

[Havoc Pennington <hp redhat com>]

Dan Winship wrote:
> But as you also said, XSMP is policy-free

I meant more to say "policy-free" in ironic quotes ;-)

> > > 		* The "Save current state" checkbox at logout will now
> > > 		  say something like "Restart the currently-running
> > > 		  applications the next time I log in". This would
> > > 		  save state for a *single* logout/login, rather than
> > > 		  saving your current state for all time until you
> > > 		  save a new state. And perhaps the button remembers
> > > 		  its state between sessions?
>
> aka "having apps guess that their last state is the one you're likely to
> want again next"

The user-visible difference is: if I just exit the app or close a 
document, then relaunch it or reopen it, was state saved; or is state 
only saved if I "save session" i.e. explicitly save state for all 
applications.

>     * Pretty much everyone seems to agree that more state saving in
>       general is good. And once you've got per-document/per-window state
>       saving implemented, it's not much harder to implement session
>       saving on top of that (you just need to remember *which*
>       documents/windows are open in addition to what their individual
>       states are).

Right. If you code magic state saving across application/document launch 
(instead of across sessions), and you have autostart, then all xsmp adds 
is a way to stick the windows to open into the command line, plus some 
stuff you don't want (like having the WM save window positions, multiple 
saved sessions, ...).

So in principle you can "save session" by listing the .desktop files and 
the documents to open them with (just as if I drag-and-drop some files 
from nautilus onto the desktop file to open those files).

> And suddenly rather than "Die, XSMP! Die!", it looks like, "well, why
> *wouldn't* we want to keep XSMP session saving around?"

My point really isn't die xsmp die (I am indifferent), but that it 
allows a lot of things that aren't useful, which are bad if they leak 
into the UI or API.

What I would say is that the application and user model should be 
reduced to maybe three things for state saving (ignoring 
logout-notification):
 - does the app start on login (autostart)
 - saving each window's state including child widgets and app-specific
   properties, when that window is closed or the app is quit, and
   restoring on each app/window launch
 - storing the set of open windows, perhaps in a single global default
   setup, OR for some apps it's probably better to just save it per-app
   or do it in some app-specific way

Things in XSMP state saving that needlessly complicate the application 
or user model:
 - multiple saved sessions (= multiple autostart dirs /
   open-window-lists)
 - having the window manager save the window states [1]
 - local vs. global vs. both
 - clone command vs. restart command
 - discard command
 - having to set a command at all, for apps that could just set a
   document list and the name of their desktop file, or for
   document-less apps, apps that could just set the name of their
   desktop file

[1] this one is a real compatibility issue; it needs to be killed 
because it's very flaky and doesn't work in the more useful state-save 
case within a session. But if you kill it, "old" xsmp-using apps won't 
work. Except noncompliant ones like gnome-terminal that just save their 
own geometry and I guess fight with the WM over which saved geometry 
wins ;-)

> Eg, something like:
>
>     gboolean (*save_state) (GtkClient *client, GKeyFile *state_file)
>
> The app just writes stuff to the GKeyFile and then returns TRUE.

It's the right idea. To really make it solid, I think you also want to 
be able to just gtk_write_window_states(state_file), and have that be 
the default handler for save_state even. heck, gtk could even write out 
the list of open windows for you also, since each window has an ID.

The thing is though, this window state saving should also happen when a 
window is just closed, not just when there's a desktop global save state 
event.

I'd guess the API should be designed so it's primarily around saving 
window states on unmap and restoring them just before map; and then 
build a "globally save all windows in the desktop" magic functionality 
on top of that.

> > On the implementation front, there is some amount of intrinsic problem
> > with libICE/libSM - they are total junk and make it difficult to write a
> > robust session manager app.
>
> But gnome-session and msm have both already dealt with this, right? Does
> the libICE/libSM suckiness leak, or can it be completely contained
> within the SM and GtkClient?

It is containable, it's purely pain for the SM implementor.

> And again, part of the point is that by adding just a little bit more
> code on top of the existing state-saving that you agree the app should
> be doing anyway, that the app gets both set-up-ability and
> resume-after-logout-ability (and, potentially in other session managers,
> recover-from-session-autosave-ability,
> multiple-different-set-up-ability, etc.)

As long as the layering is right (apps spend most of their code worrying 
about the per-app/document state saving and not 
per-session/special-global-save-event state saving) and then the 
session-state-save is built on top, I think it would work out fine as 
you say.

However, I think the only thing you need in the actual SM protocol in 
order to do it this way is a single save-yourself signal for "save the 
list of currently open documents and give me the .desktop file to stick 
in autostart" - everything else in XSMP is cruft. (everything else state 
saving related that is, again the logout notification is fine)

> If there was a strong argument for getting rid of XSMP to begin with,
> then I might not argue for adding XSMP-style session saving to its
> replacement. But if we want to keep XSMP for compatibility or whatever
> anyway, and if there's a salvageable feature (or two!) hiding in XSMP
> session saving, it seems worth it to keep that functionality.

I don't have a strong view on this, I just think it's a mistake to let 
XSMP define what you're trying to accomplish. And if XSMP legacy keeps 
the normal/useful kind of state-saving from working, or crufts up the 
control panels, then I think it would be a shame.

Havoc