Subject: Session handler fix.

From: Johan Bengtsson <[email-masked]>
Date: Wed, 10 Mar 1999 17:53:35 +0100 (CET)

Hi,
I noticed that the session managment creates a new file (with a new
name) each time you save your session, cluttering your SM_SAVE_DIR
with .fvwmXXXXaaa files. I don't know if that generally is considered
to be a feature or a bug, but I don't really like that behaviour.
Personally I don't see any reasons not to reuse the old filename,
since it is the same session, but at different points in times.

I attached a small patch that does exactly that.

	/ Johan

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 11 Mar 1999 09:04:14 +0100

> since it is the same session, but at different points in times.

Matthias, would you check this patch and commit it if necessary?

Dominik

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Matthias Clasen <[email-masked]>
Date: Sat, 13 Mar 1999 22:58:21 +0100

> Matthias, would you check this patch and commit it if necessary?

Reusing the old filename is definitively not an option, since
session managers like xsm might implement named sessions and the
user might be able to change the name of a running session. The
sm client simply doesn't know if it is asked to save its state
as a new checkpoint for the old session or as the initial
checkpoint of a renamed session. In the former case, reusing the
old filename would be ok, in the latter case, it would be wrong.

The XSM protocol has the DiscardCommand property in order to
enable the session manager to deal with this. I think fvwm
handles this properly. At least this is what I see with xsm
(other session managers may not be up to the task):

0) SM_SAVE_DIR contains just one fvwm file for a session named foo
1) start a session named foo
2) do a checkpoint for session foo:
   the old fvwm file disappears (this is xsm executing DiscardCommand)
   and a new one appears
3) repeating this many times will leave exactly one fvwm file in SM_SAVE_DIR.
4) do a checkpoint for another session name, say bar:
   the old fvwm file (for foo) stays and a new one (for bar) appears

So if you see more fvwm save files in your SM_SAVE_DIR than you
have named sessions, there must be some problem with your session 
manager not handling DiscardCommand properly, I guess...

Matthias
 
-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg