Debian Bug report logs - #10862
fvwm2: restarting fvwm2 reverses the z-order of windows

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kite.ml.org>

To: submit@bugs.debian.org

Subject: fvwm2: restarting fvwm2 reverses the z-order of windows

Date: 25 Jun 1997 19:12:44 -0000

Package: fvwm2
Version: 2.0.45-BETA-4

I have a standard Restart fvwm2 command in my fvwm2 menus. I've noticed that
when I restart fvwm2, the topmost window ends up buried under all other
windows, and in general, the z-order of all the windows just seems to be
reversed. This gets very annoying, esp. when I restart fvwm2 often to see
new menu entries provided by the debian menu system.

-- System Information
Debian Release: 1.3
Kernel Version: Linux kite 2.0.30 #13 Wed May 28 23:49:18 EDT 1997 i586 unknown

Versions of the packages fvwm2 depends on:
libc5	Version: 5.4.23-4
xlib6	Version: 3.3-2
xpm4.7	Version: 3.4g-9

Message #10 received at 10862@bugs.debian.org (full text, mbox, reply):

From: Austin Donnelly <austin@debian.org>

To: Joey Hess <joey@kite.ml.org>, 10862@bugs.debian.org

Subject: Re: Bug#10862: fvwm2: restarting fvwm2 reverses the z-order of windows

Date: Sat, 28 Jun 1997 15:34:24 +0100

On , 25 Jun 1997, Joey Hess wrote:

> I have a standard Restart fvwm2 command in my fvwm2 menus. I've noticed that
> when I restart fvwm2, the topmost window ends up buried under all other
> windows, and in general, the z-order of all the windows just seems to be
> reversed. This gets very annoying, esp. when I restart fvwm2 often to see
> new menu entries provided by the debian menu system.

Yes, I've noticed something similar happening for me.  I'll confirm
the problem later this evening, and forward your bug report upstream.

Thanks,
Austin

Message #15 received at 10862@bugs.debian.org (full text, mbox, reply):

From: Austin Donnelly <austin@greenend.org.uk>

To: Joey Hess <joey@kite.ml.org>, 10862@bugs.debian.org

Subject: Re: Bug#10862: fvwm2: restarting fvwm2 reverses the z-order of windows

Date: Sun, 29 Jun 1997 02:44:55 +0100 (BST)

On , 25 Jun 1997, Joey Hess wrote:

> I have a standard Restart fvwm2 command in my fvwm2 menus. I've
> noticed that when I restart fvwm2, the topmost window ends up buried
> under all other windows, and in general, the z-order of all the
> windows just seems to be reversed.

This is not quite true: what happens is that when fvwm2 exits, the
windows are reparented back to the X server in the reverse creation
order.  When fvwm2 starts, existing windows are picked up from
bottom-most to top-most.  This means that fvwm2 reverses the order of
windows: but not based on the stacking order.  It so happens the most
recently created window is likely to be on top, but it needn't be.

I have a patch that fixes the problem, which I'll send upstream, and
hopefully, it will be incorporated in the next upstream revision.

Austin
------------------------------------------------------------
--- fvwm.c.old	Sun Jun 29 02:33:34 1997
+++ fvwm.c	Sun Jun 29 02:34:49 1997
@@ -1245,6 +1245,21 @@
   return;
 }
 
+/* Convert from an X server "Window *" to an FVWM "FvwmWindow *" */
+static FvwmWindow *win2fvwmWin(Window win)
+{
+  FvwmWindow *ret = Scr.FvwmRoot.next;
+
+  while(ret)
+  {
+    if (ret->frame == win)
+      return ret;
+    ret = ret->next;
+  }
+
+  return NULL;
+}
+
 /***********************************************************************
  *
  *  Procedure:
@@ -1254,16 +1269,41 @@
 void Reborder(void)
 {
   FvwmWindow *tmp;			/* temp fvwm window structure */
+  Window root, parent, *children;
+  unsigned int nchildren;
+  int i;
 
   /* put a border back around all windows */
   MyXGrabServer (dpy);
 
   InstallWindowColormaps (&Scr.FvwmRoot);	/* force reinstall */
-  for (tmp = Scr.FvwmRoot.next; tmp != NULL; tmp = tmp->next)
+
+  /* We'd like to preserve the stacking order over restarts.  Since
+   * RestroreWithdrawnLocation() has the side effect of raising the
+   * window in question, we need to proceed from the bottom-most
+   * window to the top-most.  We get the current stacking order from
+   * the X server, however, it also includes all of our decorations.
+   * Therefore, we check against the Scr.FvwmRoot window list for
+   * valid windows.  Unfortunately this is an O(N^2) process, but
+   * since this is during a restart, I think it's acceptable. */
+  if(!XQueryTree(dpy, Scr.Root, &root, &parent, &children, &nchildren))
+  {
+    fvwm_msg(ERR,"Reborder","XQueryTree failed?!?");
+    MyXUngrabServer (dpy);
+    return;
+  }
+
+  if (children != NULL)
   {
-    RestoreWithdrawnLocation (tmp,True); 
-    XUnmapWindow(dpy,tmp->frame);
-    XDestroyWindow(dpy,tmp->frame);
+    for(i=0; i < nchildren; i++)
+    {
+      tmp = win2fvwmWin(children[i]);
+      if (!tmp)
+	continue; /* probably one of our decorations */
+      RestoreWithdrawnLocation (tmp,True); 
+      XUnmapWindow(dpy,tmp->frame);
+      XDestroyWindow(dpy,tmp->frame);
+    }
   }
 
   MyXUngrabServer (dpy);

Send a report that this bug log contains spam.