Subject: FVWM: windows move across restart

From: Gregory Margo <[email-masked]>
Date: Thu, 7 Dec 1995 13:06:34 -0800 (PST)

When fvwm (2.0.39) is restarted, windows on screens other than
the upper left screen change slightly in position.
This only happens on the first restart after a particular window's creation.

To illustrate, given a 2x2 desktop, whose four screens are labeled:

+-------+-------+
| (0,0) | (0,1) |
+-------+-------+
| (1,0) | (1,1) |
+-------+-------+

If you start an xterm in the empty screen (1,0), it will
place itself at geometry 80x24+0+0.  Both xwininfo and FvwmIdent report
this geometry.

Restart fvwm.

Recheck geometry of the xterm in screen (1,0).
Now xwininfo reports 80x24+-1+-1 while FvwmIdent still reports 80x24+0+0.

The window has truely moved - easily verified visually.  Only one pixel,
but now you can see the top pixel line from that xterm at the bottom
of screen (0,0).  Repeated restarts do not move the window further.

Anyone else observed this?  Is it a Bug or a Feature(tm)?  Anyone working
on it?  If it's a problem up for grabs I could take a look, but I don't
want to duplicate effort.  Chuck?

gm
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregory H. Margo                 No free speech restrictions on the Internet!
[email-masked]
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Gregory Margo <[email-masked]>
Date: Mon, 11 Dec 1995 12:21:06 -0800 (PST)

Since it seems that no one has reproduced the bug I was seeing, here
is both an improved procedure for seeing the problem, and the fix.

Please try this out if you are so inclined.  It would be nice if someone
was able to reproduce the problem and verify that the patch fixes it.

To recap: Any window that fvwm places with SmartPlacement and
RandomPlacement will exhibit this behavior:  when fvwm is first restarted
after window creation, that window will move slightly.

How to reproduce the "Windows Move Across Restart" bug.

1. Create simple demonstration control files (.xinitrc and .fvwm2rc)

   a. .xinitrc contents:

      #!/bin/sh
      fvwm2 &
      # sleep to be sure fvwm starts before xterm starts
      sleep 2
      exec xterm -C -title CONSOLE

   b. ~/.fvwm2rc contents:

      Create ~/.fvwm2rc from the default system.fvwmrc and change the
      "ActivePlacement" style default to "RandomPlacement". [And other
      changes as needed for ModulePath or fvwm filename differences.]

2. Start X

3. The "CONSOLE" xterm should be placed at geometry 80x24+1+1.
   Use both xwininfo and FvwmIndent to verify.

4. Restart fvwm from the menu.

5. The "CONSOLE" xterm should have moved to geometry 80x24+0+0.
   Both xwininfo and FvwmIdent should agree.

This "-1,-1" translation is a bug in the placement code that occurs
only if the window is placed with RandomPlacement/SmartPlacement,
and then fvwm is restarted.

The following patch fixes the problem.  The x,y and xdiff,ydiff values
will be recorded similar to the ActivePlacement/SmartPlacement code.

--- fvwm-2.0.39/fvwm/placement.c	Mon Apr 24 11:14:08 1995
+++ fvwm2-new/fvwm/placement.c	Mon Dec 11 11:41:37 1995
@@ -185,13 +185,13 @@
 		Scr.randomx = Scr.TitleHeight;
 	      if ((Scr.randomy += 2*Scr.TitleHeight) > Scr.MyDisplayHeight / 2)
 		Scr.randomy = 2 * Scr.TitleHeight;
-	      tmp_win->attr.x = Scr.randomx - tmp_win->old_bw;
-	      tmp_win->attr.y = Scr.randomy - tmp_win->old_bw;
+	      tmp_win->attr.x = Scr.randomx - tmp_win->old_bw + tmp_win->bw;
+	      tmp_win->attr.y = Scr.randomy - tmp_win->old_bw + tmp_win->bw;
 	    }
 	  else
 	    {
-	      tmp_win->attr.x = xl - tmp_win->old_bw;
-	      tmp_win->attr.y = yt - tmp_win->old_bw;
+	      tmp_win->attr.x = xl - tmp_win->old_bw + tmp_win->bw;
+	      tmp_win->attr.y = yt - tmp_win->old_bw + tmp_win->bw;
 	    }
 	  /* patches 11/93 to try to keep the window on the
 	   * screen */
@@ -214,8 +214,8 @@
 	      Scr.randomy = 0;
 	    }
 
-	  tmp_win->xdiff = tmp_win->attr.x - tmp_win->bw;
-	  tmp_win->ydiff = tmp_win->attr.y - tmp_win->bw;
+	  tmp_win->xdiff = tmp_win->attr.x + tmp_win->old_bw - tmp_win->bw;
+	  tmp_win->ydiff = tmp_win->attr.y + tmp_win->old_bw - tmp_win->bw;
 	}
       else
 	{	  

Please let me know if you can exhibit the problem, if the patch works,
if I'm totally out of my mind, or if your sister is single :-)

In case it matters, this is my environment:
Linux-1.2.13
GCC-2.7.0
Libc-5.0.9
XFree86-3.1.2-elf
Screen set to 1024x768, 256 colors.

thanks,
gm