Subject: Re: 'Sticky' problem during restart - PART TWO

From: Giuseppe Della Ricca <[email-masked]>
Date: Wed, 27 Dec 2000 16:40:37 +0100 (CET)

Dear Dominik,

concerning the 2nd problem I've reported, it looks like it was *still* there
this morning when I synchronized with CVS, i.e. after your commit:

2000-12-27  Dominik Vogt  <[email-masked]>

        * FvwmForm/FvwmForm.c:
        * FvwmForm/FvwmForm.h:
        moved global initialisation into .c file

[BTW, I had to remove some 'extern' declarations to be able to link
 FvwmForm, I hope correctly]

I've used the following .fvwm2rc for my tests:

------
Style Fvwm*          Sticky

AddToMenu MenuFvwmRoot "Restart" Module FvwmForm FvwmForm-Restart

DestroyModuleConfig FvwmForm-Restart: *
*FvwmForm-Restart: GrabServer
*FvwmForm-Restart: WarpPointer
*FvwmForm-Restart: Button     quit "Restart" ^M
*FvwmForm-Restart: Command    Restart fvwm2
------

but after changing the 'Restart' into 'Restart --dont-preserve-state' the
problem disappeared ...

My (crazy ? I don't know !) is that 'Restart' was writing something wrong in
.fs-restart and as a consequence FvwmForm-Restart was behaving strangely
(starting on a desk different from the current one, being visible from the
Pager but not in the corresponding desk).

Since it was somehow 'random', I hope it will not start again as soon as
I send this mail ....

What do you think ?

Cheers,
Giuseppe.

PS
Please CC if you need a fast reply: I'm not on the list.

--
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: Dominik Vogt <[email-masked]>
Date: Fri, 29 Dec 2000 13:33:37 +0100

>  FvwmForm, I hope correctly]

Yes, my fault.

> .fs-restart and as a consequence FvwmForm-Restart was behaving strangely

Maybe.

> Pager but not in the corresponding desk).

Is this what you *saw*?  In this case it's almost certainly fixed
with my latest commits.  If I'm correct, it's a combination of two
bugs.  The one you described in (1): sticky windows vanish after a
restart, and one in our session management:  if a window dies over
a restart, another window may reuse the same window id later.  I
believe we already catch this if the window belongs to a different
application (Mikhal, is this right?) but not if the same
application - in this case FvwmForm - creates the window.
Thus - although hours may have passed since the last restart - the
new FvwmForm window reuses the session management information -
which contained the old desk number.  So a fairly reliable way to
create this should be this:

 1) Start fvwm with a minimal .fvwm2rc file that only defines the
    form, makes it sticky and adds menu entries to switch between
    desks 0 and 1 and an entry for the quit form.  No windows are
    created (not even FvwmPager).
 2) Switch to desk 1.
 3) Restart using the form.  The window is killed before fvwm is
    restarted.
 4) Still on desk 1, restart fvwm again.
 --> The new form should reuse the old window id since no other
     windows were created in between (of course this depends on
     what the X server does).  Thus it will be affected by the
     sticky/restart bug.

> Since it was somehow 'random', I hope it will not start again as soon as

This randomness can easiy be explained by the condition that the
window myst get the same window id as the last time when fvwm was
restarted.

Both problems are fixed now.  Mikhael, it would be nice if you
have a look at the changes I made to the SM code (look for the
DisableSM() and VerifyVersionInfo() functions).

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]

---

From: Giuseppe Della Ricca <[email-masked]>
Date: Fri, 29 Dec 2000 14:35:41 +0100 (CET)

On Fri, 29 Dec 2000, Dominik Vogt wrote:

> with my latest commits.

YES, both PART ONE and PART TWO are fixed now, as far as I can see.
Thanks a lot !!

Cheers,
Giuseppe.

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 29 Dec 2000 21:13:52 -0600

On 29 Dec 2000 13:33:37 +0100, Dominik Vogt wrote:
> 
> If I'm correct, it's a combination of two
> which contained the old desk number.

Yes, this is correct, only when the window id and its argv[] are the same,
the state is applied. If a client is session aware (like all GNOME apps),
the match is always exact, since client_id is used (37 unique chars).

Actually it was nice to get a new FvwmConsole or FvwmForm in the place in
which the previous one (with the same alias) was on Restart. But since
this only works if X gives the same id, it is ok to disable this "feature"
for consistency.

> DisableSM() and VerifyVersionInfo() functions).

Seems ok. But it is probably not very good to increase a version every
time automatically.

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.

Ideally, instead of using __DATE__ it would be nice if a state file
version is increased manually every time the format of this file changed,
either directly, or indirectly (say, by changing the window structure).

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...

Nothing of the above is critical. Thanks.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 30 Dec 2000 08:28:27 +0100

> the match is always exact, since client_id is used (37 unique chars).

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.

> 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.

Overall I think the benefit - we won't get all these bug reports
that were caused by a window structure change, or at least will be
able to identify them by the warning in the console - outweighs
the cost: having to restore some things manually.  But at least
that is something you would expect after an upgrade.

> either directly, or indirectly (say, by changing the window structure).

Of course this was my first idea also, but I couldn't come up with
something that works automatically (even without running configure
again) and is portable.  Perhaps a checksum calculation over the
relevant parts of the window structure would do the trick.  But
how can this be done with automake and without reimplementing a
C compiler?
 
> 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.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 30 Dec 2000 20:28:03 -0600

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.

> with some malloced members.  Once these have been used they are

It is only allocated once. I think it is safe to free it in DisableSM().

> 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().

> in case some braindead compiler generates code for an "if (0)"

I spoke about other code:

  cvs diff -D 17-Dec-2000 -D 18-Dec-2000 session.c

Happy New Year. :)

Regards,
Mikhael.