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

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

Dear Dominik,

I'll start discussing the 1st problem (you'll see, it's a long story !!).
I've used the following .fvwm2rc for my tests:

------
Style Mxconns        Sticky
Style Pload          Sticky
Style Fvwm*          Sticky
Style XLoad          Sticky

Mouse 2         I       A       Iconify

DestroyFunc InitFunction
AddToFunc InitFunction    I Echo Starting fvwm ...
+                         I Module FvwmPager 0 4

DestroyFunc RestartFunction
AddToFunc RestartFunction I Echo Restarting fvwm ...
+                         I Module FvwmPager 0 4

AddToMenu MenuFvwmRoot "test1"            Restart
+                      "test2"            Restart --dont-preserve-state
------

and I've applied your fprintf to add_window.c

The problem of some sticky windows becoming 'ghosts' after a restart done
from a desk different from the first, i.e. 'Desk 0', affects only Xload, Pload
and Mxconns (Pload is an app. showing the in&out traffic on eth0 or ppp0,
Mxconns is an X11 proxy I use as a filter to X11 connections), while ASClock is
not affected (I'm using it here just for cross-check).

All of them are 'simple' applications, so no funny icon specific
configurations.

If I do a restart from MenuFvwmRoot (using the item 'test1'), I obtain:

new frame: 960 0 55x73 d=0            <- asclock
new frame: 7 394 593x370 d=0          <- 1st xterm window
                                         (tail -f log/fvwm2.log)
new frame: 264 184 593x370 d=0        <- 2nd xterm window
                                         (this mail)
new frame: 735 621 289x31 d=0         <- mxconns
new frame: 726 0 234x80 d=0           <- pload
new frame: 840 80 134x167 d=0         <- xload
[FVWM][Echo]:  Restarting fvwm ...
new frame: 119 1 508x116 d=0          <- FvwmPager

if I move to another desk, for example 'Desk 1', I do the Restart and then I
go back to 'Desk 0' (to check the log and keep on writing), the log says:

new frame: 960 0 55x73 d=0            <- asclock
new frame: 7 394 593x370 d=0          <- 1st xterm window
new frame: 264 184 593x370 d=0        <- 2nd xterm window
new frame: 735 621 289x31 d=1         <- mxconns
new frame: 726 0 234x80 d=1           <- pload
new frame: 840 80 134x167 d=1         <- xload
[FVWM][Echo]:  Restarting fvwm ...
new frame: 119 1 508x116 d=1          <- FvwmPager

I see here some inconsistency: the xterms are on d=0, this is fine, I've left
them there. FvwmPager is on d=1, and since it's sticky I can understand this.
But also asclock is sticky, and it has d=0, while the 'ghosts' mxconns, xload
and pload (they have disappeared from all desks !!!) have d=1 !

Both mxconns, xload and pload are still there, I can see them with Alt-Tab:
if I select one of them from the list, the pointer moves to the position
the app was before the restart, and also the geometry info in Alt-Tab
is correct.  The windows are just 'hidden'.

Now, from 'Desk 0' I issue another Restart, and during it I can see again
(for a short time) the two applications in the right positions: when the
Restart is completed, they are iconified. The same happens is I restart from
'Desk 1'.

This is after a restart from Desk 0:

new frame: 960 0 55x73 d=0
new frame: 7 394 593x370 d=0
new frame: 264 184 593x370 d=0
new frame: 735 621 289x31 d=0
new frame: 726 0 234x80 d=0
new frame: 840 80 134x167 d=0
[FVWM][Echo]:  Restarting fvwm ...
new frame: 119 1 508x116 d=0

This is after a restart from Desk 1:

new frame: 960 0 55x73 d=0
new frame: 7 394 593x370 d=0
new frame: 264 184 593x370 d=0
new frame: 735 621 289x31 d=1
new frame: 726 0 234x80 d=1
new frame: 840 80 134x167 d=1
[FVWM][Echo]:  Restarting fvwm ...
new frame: 119 1 508x116 d=1

Now, if I issue the restart from a desk different from 0, I enter in a sort of
a loop: 'ghost'-iconic-'ghost'-iconic' and so on ... (if I stay in a desk
different from 0).
If I de-iconify those apps. at the next restart they disappear, and at the
next+1 they're iconified again, and so on ...

*****
And now (WOW !) my workaround: if instead of using a plain 'Restart' I use
'Restart --dont-preserve-state' (i.e. 'test2') everything works fine !!!

(just found by chance ... trying all possible things ...)

(BTW, are you using Restart --dont-preserve-state ?)

I've checked that the HOME/.fvwm/.fs-restart-HOSTDISPLAY file is created
correctly, and looks ok both when restarting from d=0 and d=1 (just the
desk of the sticky windows is 0 or 1, respectively).

Should then 'Restart --dont-preserve-state' be the default ?
*****

Since it affects also xload, I hope you can reproduce it easily.

Cheers,
Giuseppe.

PS
Please CC if you need a fast reply, since 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: Mikhael Goikhman <[email-masked]>
Date: Thu, 28 Dec 2000 08:33:01 -0600

I only want to clarify some things.

> (BTW, are you using Restart --dont-preserve-state ?)

I know, Dominik uses this by default. I myself use the plain Restart
without parameters and I would suggest to do the same when possible.

> Should then 'Restart --dont-preserve-state' be the default ?

Currently Restart uses the same (almost) mechanism like when fvwm is
session managed (i.e. is running under a session manager). The idea is
to have the same state as before restart. This is done by dumping some
window-specific and global state into .fs-restart-DISPLAY file.
This also means that some changes to your .fvwm2rc may be overwritten.

'Restart --dont-preserve-state' mostly means to run fvwm from stratch like
on start-up (just calling RestartFunction instead). No .fvwm2rc settings
will be overwritten, i.e. no old dynamical state is restored (except for
one stored in X, like iconifying).

You should choose one or another accordingly to your needs. For example,
make (dynamically) one window shaded, one window sticky. Restart without
paramenters. Both windows are in the exactly same state as before Restart.
Now do 'Restart --dont-preserve-state'. Both windows are unshaded and
non-sticky (or whatever your .fvwm2rc says them to be).

------------

The problem (not related to this sticky problem). Currently the state file
format is not very good, there are no versioning, and some flags (like
window flags) are stored as integer instead of named attributes. So if
Dominik in 2.3.24 changes the window structure, and you run 2.3.22, then
upgrade to 2.3.25 and Restart, your windows may be in funny state (even
wrong geometry). Quit or manual correction or closing these windows cures
the situation. This may only happen on the first Restart. On the next
Restart's the state should be restored correctly. This is an old known
problem with developement versions.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 29 Dec 2000 08:57:56 +0100

Problem fixed :-)

The reason was that when using SM restart (i.e. issuing a plain
'Restart' without '--dont-preserve-state'), the SM code preserved
the desk number for sticky windows (session.c, line 703/704):

  SET_STICKY(ewin, IS_STICKY(&(matches[i])));
  ewin->Desk = matches[i].desktop;

Of course for sticky windows the desk must always be the current
desk, so this code is correct:

  SET_STICKY(ewin, IS_STICKY(&(matches[i])));
  ewin->Desk = (IS_STICKY(ewin)) ? Scr.CurrentDesk : matches[i].desktop;

(ewin is the newly captured window and matches[i] is a structure
that contains information about the previous state of the window).

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: Dominik Vogt <[email-masked]>
Date: Fri, 29 Dec 2000 08:23:55 +0100

> is correct.  The windows are just 'hidden'.

Okay, with these instructions I see it too.  The pager will always
be on the correct vieport because it is killed and restarted
during a restart, ba the way.  Of course this is a bug.  I'll see
what I can do.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 29 Dec 2000 13:12:16 +0100

> problem with developement versions.

... and it's no longer a problem.  The state file now contains the
version number and build date and is ignored if this information
does not match the fvwm build that was just restarted.  On one
hand, this will help people who upgrade from one beta to another,
or even upgrade to a newer snapshot (one built every day).  On the
other hand this will not disable the state file for us (the
developers) on every restart, except if one build is before and
the next one after midnight.

Bye

Dominik ^_^  ^_^