[bug #13735] session management wanted


                 Summary: session management wanted
                 Project: GNU Midnight Commander
            Submitted by: ossi
            Submitted on: Mon 07/11/2005 at 19:23
                Category: None
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
                 Release: current (CVS or snapshot)
        Platform Version: All



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
(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;;

# 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


Reply to this item at:


  Message sent via/by Savannah

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]