Subject: Re: Restoring global and window state (Restart and SM)

From: Dominik Vogt <[email-masked]>
Date: Wed, 3 Jan 2001 18:51:05 +0100

On Sat, Dec 30, 2000 at 08:28:03PM -0600, Mikhael Goikhman wrote:
> I think, some confusion is caused by the fact that the same code
> participates in 2 complitely different situations - SM and Restart.
> Actually there is also a third situation of Restart under SM.
> 
> SM stands for a session management. FVWM tries to be XSMP compliant
> (the protocol of communication between a session manager, like xsm, DTSM
> or gnome-session, and its clients). In other words, FVWM is a session
> aware client. But unlike other clients, a window manager is a bit special
> in that it should store/restore a window state of other clients.
> 
> Most of users don't run FVWM under a session manager, so in their case
> XSMP protocol is not used. Restart only uses the internal FVWM's mechanism
> of storing/restoring the state, it does not use any real SM functionality.
> 
> Example (not applicable for users running FVWM directly). A user runs xsm,
> which in its turn runs all clients from the previously stored session, one
> of these clients is FVWM. Once FVWM detects a session manager, it
> communicates with it and listens to events like save-state, shutdown.
> Load-state is always caused on the FVWM's start-up, and -restore parameter
> tells which state file to use.
> 
> My understanding is that on Restarting only the state of already
> mapped windows needs to be applied, while on start-up under a session
> manager both mapped and yet to be added windows should be matched.

Thanks for the clarification.

> On 30 Dec 2000 08:28:27 +0100, Dominik Vogt wrote:
> > 
> > By the way, should we take care of the SM memory leak?  The
> > information from the state file is stored in malloced structures
> > with some malloced members.  Once these have been used they are
> > never freed.
> 
> It is only allocated once. I think it is safe to free it in DisableSM().

Safe yes, but difficult to do.  If we simply free the whole
structure, we'll create real memory leaks that purify/insure++
will detect.

> > > Imagine a user of gnome-session and fvwm inside it. The user has 15
> > > windows, which he placed nicely over its desks/pages (some shaded or
> > > iconified). Now after every recompiling of fvwm and starting X,
> > > gnome-session starts all 15 windows, but fvwm refuses to apply the old
> > > state and places all of them on the first page loosing their state.
> > 
> > First of all, I really can't imagine why anybody except the
> > developers should reinstall a window manager from a running
> > session (just my opinion).  Second, I'm not sure which information
> > will be lost over a restart in this case.  Personally I never use
> > SM (with --dont-preserve-state), but the only things I know of
> > that fvwm does not remember are the position of module windows and
> > if a window was shaded or not (and some global info like the
> > current desk and page).  I does remember page and desk of windows.
> 
> This is because you only feel session.c on Restart when all windows are
> already mapped, this is not a case in my example.
> 
> I hope I explained above that a user of SM will have the state file loaded
> (and applied) on FVWM's start-up, not only on Restart. In his case the
> state files are called .fs-UNIQUE instead of .fs-restart-DISPLAY.
> 
> Having or not having --dont-preserve-state has nothing to do with SM.
> Session management is not used by a mere fact that one doesn't run FVWM
> under a session manager. Actually a new DisableSM() should better be
> named DisableRestoringState() or DisableRestoringStateAfterRestart().

I'll do that.

> > > BTW, you removed a code, which by Matthias's intends should restore the
> > > stack order of these 15 windows. Some time ago I disabled it, because it
> > > didn't work correctly with session manager (it worked ok without it).
> > > I should write comments next time...
> > 
> > Oh, I simply commented it out since it was disabled anyway - just
> > in case some braindead compiler generates code for an "if (0)"
> > branch.
> 
> I spoke about other code:
> 
>   cvs diff -D 17-Dec-2000 -D 18-Dec-2000 session.c

Um, I really can't remember removing that stuff.  Not to speak of
a reason why (other than that I sometimes remove commented code
that was in for years).

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [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]