Definitions
A session is a group of running applications, each of which has a particular state. The session is controlled by a service called the session manager. The applications participating in the session are called session clients.
The session manager issues commands to its clients on behalf of the user. These commands may cause clients to commit unsaved changes (for example by saving open files), to preserve their state for future sessions, or to terminate gracefully. The set of these operations is called session management.
In the common case, a session consists of all applications that a user runs on their desktop at a time. Under Unix/X11, however, a session may include applications running on different computers and may span multiple displays.
Has anyone written an Tcl extension to allow Tcl applications to properly register to a session manager?
On Unix/Linux, you can get a list of session clients with the command xlsclients
Unfortunately, at least on my Solaris machine, xlsclients does not list Tk based applications!:
In window 1, I type: $ wish %
In window 2, I type: $ xlsclients -a -l | grep -i wish $
In fact, not even all of the X applications are listed.
X session management has been centered around libSM, which has come with X for years. It is shared by GNOME and KDE - even twm. Standards documents on include ftp://ftp.x.org:21/pub/R6.4/xc/doc/hardcopy/SM/SMlib.PS.gz and ftp://ftp.x.org/pub/R6.4/xc/doc/hardcopy/SM/xsmp.PS.gz
See also the ICCCM section on SM. For GNOME apps, use the GnomeClient object. For a simple example of using libSM directly, twm/session.c in the twm source code is pretty easy to understand.
TV Playing one's own session manager can be very advantages, also as a first step to prepare automated (tcl) scripts to start and control cooperating programs. First, one wants to start and stop programs, which under tcl would be with the exec command mainly.
Killing a program under tcl requires the use of an external kill program, under linux/unix it would have the name kill itself, and require an argument which is the PID (process IDentifier), which an be gotten from a list of the processes under linux/unix by the command ps.
ps -aef | grep your_process_name
probably can give you your desired proces id from the list (ps gives you one process per line, use man to figure out which entry is supposed to be the actual pid (and not the parents process).
Under windows (at least XP) I yesterday figured out the kill command is
tskill <pid>
and when you're using cygwin you can figure out the windows PID by using
ps -W
When you want to kill or send a message (like suspend, sleep, or kill) to a cygwin started process, the normal unix ps and kill under cygwin can be used, which cygwin will render to the correct windows calls. On the Mac I don't know of an equivalent, except maybe a script to kill an application, and I don't have one currently to try.
When you use pcom you can use the DO_TCL prefix on the normal entry to type messages (the top one) to execute a TCL command on the connected pcom on the other side. Pcom will take the whole rest of the line after DO_TCL and evaluate it as a tcl command. For process starting and messaging (killing) one would want to use DO_TCL exec ...., which works fine. The bottom (status) window in pcom will show the return value of the command remotely executed. Pcom can be connected over any internet connection accross all types of machines.
There is binary variable allowtcl (by heart, you'd need to check this) whose value determines whether the DO_TCL behaviour will be permitted on the receiving Pcom, to make sure one can turn it off. Of course remote tcl commmands with no limitation are a complete potential security loophole, so should be used with some care. And alternative would be to add a command to the event handler / message parser, which is not so hard, to allow just specific, pre-encoded commands.
Also you'd probably want session management to be limited to a number of possible parties, which in pcom is possible by adding for instance peer IP address checks in the server socket handler (which I did on an 24/7 internet machine to allow only locally originating connections, not for nothing, I assure). In fact using a basic socket connect and write / read setup is enough to manage a remote session, it's just easier with bwise.
For general session management considerations, using X windows standards, one can use similar techniques on Linux/Unix as well as on windows by using a windows running Xserver, like XFree86. There is even a complete recent KDE setup ported to windows platforms, which even should run out-of-the-box, except I think you should already have cygwin. Not cheap on memory, not blazing fast necessarily but it runs and makes transparent tcl/tk bases session management easier. If you want to run the session scripts using Tk which on winows also appears under X, wish can be compiled under cygwin as a X version, not a windows version, though that gives you evident shared library issues.
See http://www.geocrawler.com/archives/3/263/1997/11/50/1417910/ for a discussion of some of the terms and details.
See also: