Subject: Re: stacking order bug

From: Matthias Clasen <[email-masked]>
Date: Sat, 9 Jan 1999 00:53:43 +0100

I think the problem observed with tkbiff (and also with Emacs 
raise-frame) is a result of fvwm loosing track of the exact stacking order
when clients restack their own toplevel windows. tkbiff uses (as far as I
could tell from quickly peeking into the tk sources) XReconfigureWMWindow 
for its autoraising which tries to use XConfigureWindow and
(since this fails for reparenting wms) then generates a synthetic 
ConfigureRequest for the toplevel window. fvwm handles this by
issuing a XConfigureWindow on the corresponding frame(s), but it 
doesn't update its own stacking order (in HandleConfigureRequest). 

The patch below inserts a call to a routine there that reconstructs fvwms
stacking order from the result of an XQueryTree. Hopefully clients will only
occasionally restack their own windows, so that this shouldn't be a
performance problem. One could optimize this somewhat and correct the stacking
order directly without XQueryTree for simple cases (Above, Below). 

Matthias

--- events.c.orig	Fri Jan  1 21:50:52 1999
+++ events.c1	Fri Jan  8 23:56:10 1999
@@ -132,6 +133,51 @@
 #endif /* SHAPE */
 }
 
+
+void 
+resync_stacking_order (void)
+{
+  Window root, parent, *children;
+  unsigned int nchildren, i;
+  FvwmWindow *t;
+
+  MyXGrabServer (dpy);
+
+  if (!XQueryTree (dpy, Scr.Root, &root, &parent, &children, &nchildren)) 
+    {
+      MyXUngrabServer (dpy);
+      return;
+    }
+
+  Scr.FvwmRoot.stack_next = &Scr.FvwmRoot;
+  Scr.FvwmRoot.stack_prev= &Scr.FvwmRoot;
+
+  for (i = 0; i < nchildren; i++) 
+    {
+      for (t = Scr.FvwmRoot.next; t != NULL; t = t->next) 
+	{
+	  if (t->frame == children[i]) 
+	    {
+	      break;
+	    }
+	}
+
+      if (t != NULL) 
+	{
+	  /* prepend fw to the new  ring we're building at tmp_head */
+	  t->stack_next = Scr.FvwmRoot.stack_next;
+	  t->stack_prev = &Scr.FvwmRoot;
+	  Scr.FvwmRoot.stack_next->stack_prev = t;
+	  Scr.FvwmRoot.stack_next = t;
+	}	
+    }
+  
+  MyXUngrabServer (dpy);
+  
+  XFree (children);
+}
+
+
 /***********************************************************************
  *
  *  Procedure:
@@ -1367,6 +1412,8 @@
                       cre->value_mask & (CWSibling | CWStackMode), &xwc);
 DB(("HandleConfigureRequest: reconfiguring frame window 0x%x for CWSibling|CWStackMode (sendEvent enabled)", Tmp_win->frame));
     sendEvent = True;
+    
+    resync_stacking_order();
   }
 
 #ifdef SHAPE

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Bob Woodside <[email-masked]>
Date: Sat, 9 Jan 1999 00:42:16 -0500 (EST)

Matthias Clasen <[email-masked]> wrote:
> raise-frame) is a result of fvwm loosing track of the exact stacking
> order when clients restack their own toplevel windows.

	You're absolutely right. Sorry I haven't kept you posted on my
progress the last few days - it's been a very busy week (that pesky day
job and all!)

	My original diagnosis was flawed (not an unusual state of
affairs!) - I was looking at the wrong window. In fact, we get a very
orderly ConfigureRequest when tkbiff does a raise, but as you pointed
out, I overlooked that bit of code in events.c when I added the stacking
order chain.

	I've taken a different approach from your patch, but it works
quite nicely. If the window is one of ours, I simply pluck it from the
chain and reinsert it depending on the sibling position (or lack thereof).

	I'm still testing things, but so far tkbiff is happy, as are a
couple of other apps that do their own raising, and the override_redirect
windows (of course, I re-enabled your original patch). I should be able
to commit the fix sometime this weekend.

- Bob

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 9 Jan 1999 07:59:36 +0100

> to commit the fix sometime this weekend.

Nice to hear we will have it fixed for 2.2 after all. I think this
is the same problem as mentioned in the TODO file:

  - If programs raise their own windows (XEmacs 'other-frame', for example)
    new stacking order isn't communicated to fvwm

When you check in the fix, could you remove this from the TODO
then?

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: Matthias Clasen <[email-masked]>
Date: Sat, 9 Jan 1999 21:59:20 +0100

> to commit the fix sometime this weekend.

This was the optimization for Above/Below which  i mentioned. If you 
ever come across a client that uses TopIf, BottomIf or Opposite
to restack its windows, I think you'll have  to use XQueryTree to 
reconstruct the stacking order. Fvwm could of course decide to just
drop these highly unlikely configure requests.

---

From: Bob Woodside <[email-masked]>
Date: Sat, 9 Jan 1999 21:18:19 -0500 (EST)

> drop these highly unlikely configure requests.

	We've been thinking along much the same lines: I started at one
end, you at the other, and we met in the middle. I use the XQueryTree
as a last recourse for the 3 oddball stack modes, though I really
wanted to ignore them (why anyone might think them useful for a top
level window escapes me).

	I committed the fix to CVS a little while ago. This also
includes re-enabling your override_redirect avoidance fix.

- Bob