savannah: session management wanted

[slavazanko]

Original: ​http://savannah.gnu.org/bugs/?13735

Submitted by:	Oswald Buddenhagen <ossi>	Submitted on:	Mon 11 Jul 2005 07:23:48 PM UTC
Category:	None	Severity:	3 - Normal
Status:	None	Privacy:	Public
Assigned to:	None	Open/Closed:	Open
Release:	current (CVS or snapshot)	Operating System:	All

Discussion:
{{
Mon 11 Jul 2005 07:23:48 PM UTC, original submission:

this one is from the more exotic department ... :)

in a "heavily x-windowed environment" you want session management.
basically this means two things:
(1) saving application state across session exit and restoration
per-instance (per-window). for mc this includes panel locations,
mode (normal, view, edit), cursor positions in panels, viewer,
editor, most/all options.
(2) prevention of data loss at session exit. for mc this is
essentially unsaved files in mcedit.

under x the standard protocol is xsmp (google for it, the first hit
is right :).
the session manager is a server that runs on the x client; there is
no connection to the x protocol itself.
basically it works this way: on session exit, there is a first
broadcast "is it ok to end the session?". the clients with unsaved
data can pop up asking what to do (save/discard/cancel [shutdown]).
if the first round is successfull (no app objects the shutdown), a
second round of broadcasts is send around, this time "safe yourself
requests". every app is required to save its state in whatever way
it wants, as long as this state information is kept away from the
other instances of the same app. additionally, the app must tell
the session manager what should be started upon session restoration
to bring back the app into the state it left off. usually this is
the command name of this app with some instance identifier.

as mc is no "native" x client, we have to go through some hoops to
get what we want.
(2) requires that the app somehow gets the user's attention. there
is no way around x in this case. fortunately, about any x terminal
emulator exports the own window id in the WINDOWID env variable. thus we can simply do something like that:
XRaiseWindow(mydpy, getenv("WINDOWID"));
XSetInputFocus(mydpy, getenv("WINDOWID"), RevertToParent?, CurrentTime?);
(1) is a bit more tricky. as mc runs nested into a terminal
emulator, communicating the correct restart command to the session
manager is a problem. what we really want is a command line like
"xterm -geometry ... -e mc --session foo". i seriously doubt that
xsmp provides any means to do "command line merging", so mc cannot
just extend xterm's restart command. however, i think the following
would work: create a wrapper script xmc:

---

#! /bin/bash
# usage: xmc [--mc-option] ... terminal-emulator [options ...]

# this is a trivial version; it only works with --parm=arg options
# (i.e., single-element options). a full version needs to know each
# option's argument requirements.
while $# != 0; do
case $1 in
--*) opts=("$opts[@]" "$1"); shift;;
*) break;;
esac
done

# uuidgen is currently part of libuuid1 on debian
exec "$@" -e mc --session ~/.mc/sessions/$(uuidgen) "$opts[@]"

---

that way xterm (or whatever) sees a command line that already
contains the identifier of a session, which mc can use for its
purposes. as xterm saves the complete client command line across
sessions, we don't have to tell the session manager anything,
things just work ...

note that somebody simply clicking away the xterm window is not
relevant to the matter of session management. well, one could still
do some crash recovery, but that would be A Goog Thing (TM)
independently of session management.
}}