id summary reporter owner description type status priority milestone component version resolution keywords cc blockedby blocking branch_state votes 24 savannah: session management wanted slavazanko "Original: http://savannah.gnu.org/bugs/?13735 ||Submitted by:||Oswald Buddenhagen ||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. }}} " task new minor future releases mc-core ossi@…