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.