Subject: StackingOrder patch

From: Bob Woodside <[email-masked]>
Date: Thu, 12 Nov 1998 15:51:57 -0500 (EST)

Does anyone have strong feelings one way or the other about
merging my StackinOrder patch into this release? (A detailed description
can be found at http://www.pcnet.com/~proteus/Fvwm/StackingOrder.html.)

	Brad, if my middle-aged memory isn't playing head-games with me,
I think you were one of the first people to grab this one. Any comments?

- Bob

--
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: Brad Giaccio <[email-masked]>
Date: Thu, 12 Nov 1998 22:21:25 -0500 (EST)

> I think you were one of the first people to grab this one. Any comments?

Okay then,
	Pretty please with sugar on top can I have it again, pleaeeeeeee.
But seriouslly.  I am often forced to leave my cushy Ultra 1 and work on a
sparc 2s and sometimes if intel machines( shudder).  And the speed
increase your patch provides is phenomenal.  just the time saved in
redraws makes more than one desktop usable on older machines and even the
newer ones too.

So in short Bob you have my votes.

Brad

---

From: Dan Espen <[email-masked]>
Date: Thu, 12 Nov 1998 23:03:07 -0500

> I think you were one of the first people to grab this one. Any comments?

The description  sounds great, Brad's comments   are all positive, and
although I've never tried it, I think my home Sparc 1+ is really going
to  like it.  (It  should be a Sparc  5, if I  take some time off from
fvwm2 work.)

You've got my vote.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
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: Jason L Tibbitts III <[email-masked]>
Date: 12 Nov 1998 22:56:14 -0600

>>>>> "BW" == Bob Woodside <[email-masked]> writes:

BW> Does anyone have strong feelings one way or the other about merging my
BW> StackinOrder patch into this release?

This looks to have negligible impact on footprint and on regular
performance.  If it indeed helps things on slower machines thin it's
probably a very good thing; we need to do whatever possible to cater to the
low end.

Plus, that stacking order inversion on restart has always bugged the crap
out of me.

 - J<

---

From: Austin Donnelly <[email-masked]>
Date: Fri, 13 Nov 1998 13:44:43 +0000

> Plus, that stacking order inversion on restart has always bugged the crap

It's not the stacking order which changes - it reversed the windows in
the order they were created.  This is Debian Bug#10862 (see
http://www.chiark.greenend.org.uk/debian/Bugs/db/10/10862.html)

I posted a patch that fixes this problem over a year ago.  The
original bug report is around 500 days old.

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);

---

From: Bob Woodside <[email-masked]>
Date: Fri, 13 Nov 1998 10:15:27 -0500 (EST)

> http://www.chiark.greenend.org.uk/debian/Bugs/db/10/10862.html)

	Well, the stacking order *is* changed by the time the Restart is
finished. And the current code doesn't really reverse the windows in order
of creation, either. They're reversed in the order in which windows have
been focused (but not necessarily raised): that's the way the window chain
is maintained. That's why the order isn't precisely this thing or that
when the Restart is finished.

> I posted a patch that fixes this problem over a year ago.

	Yes, since Fvwm currently has no idea of the windows' stacking order
(it only knows who's on top), your patch had to ask the X server all about
it. However, when (for other purposes) I decided that Fvwm should be keeping
track of the stacking order all along, it occurred to me that a simple 
change to the loop control in Reborder, using the new stacking order chain,
would elimnate this misfeature without any need to query the server.

>  The original bug report is around 500 days old.

	And it's about time we eliminated the bug! I'll be putting the fix
into CVS this weekend.

- Bob

---

From: "Randall S. Winchester" <[email-masked]>
Date: Fri, 13 Nov 1998 13:23:40 -0500 (EST)

On Thu, 12 Nov 1998, Dan Espen wrote:

: Bob Woodside <[email-masked]> writes:
: > 
: > 	Does anyone have strong feelings one way or the other about
: > merging my StackinOrder patch into this release? (A detailed description
: > can be found at http://www.pcnet.com/~proteus/Fvwm/StackingOrder.html.)
: > 
: > 	Brad, if my middle-aged memory isn't playing head-games with me,
: > I think you were one of the first people to grab this one. Any comments?
: 
: The description  sounds great, Brad's comments   are all positive, and
: although I've never tried it, I think my home Sparc 1+ is really going
: to  like it.  (It  should be a Sparc  5, if I  take some time off from
: fvwm2 work.)
: 
: You've got my vote.

Humm.... maybe I could even stomach running fvwm2 to my house down my ISDN
line! Currently I just use the Windows Window manager (NT or Win95) which
has really stupid focus policies. I always have things overlapping, even
with two monitors each with their own virtual windows.

I really like performance improvements.
YAV -- Yet another vote

Randall