The StackingOrder Patch

    *This patch is against the FVWM 2.0.46 base.*

    This patch does three things.

    First, it makes FVWM keep track of the stacking order of the windows,
by using a second set of chain pointers (the original chain keeps track
of the order in which windows have been focused, which is often not the
same as the stacking order). So now FVWM can easily answer the question
"who's on third?" at any time.*

    Second, by using this new-found knowledge, FVWM will reparent windows
back to the root window (on a Restart or a Recapture operation) in the
reverse of the current stacking order. This eliminates the old quirk
of having the stacking order appear more or less reversed after restarting
FVWM.

    Third, it restructures the the Desktop and Viewport (page) switching
routines to perform a simultaneous bidirectional loop through the window
list (via the new stacking order chain). Windows that are moving off the
visible screen are unmapped/moved from the bottom of the stacking order
upwards. Windows that are moving onto the visible screen are mapped/moved
from the top down.

    The intent is to minimize the amount of expose/redraw overhead during
these operations when there are a number of overlapping windows involved.
It also serves to equalize  the visual disturbance between the moving-out
and the moving-in operations. Previously, moving out of a page/desktop 
with many overlapping windows could be disturbing and slow because, as the 
windows moved from the top down, the ones underneath got redrawn as they
were exposed. Moving into such a page/desktop, on the other hand, would 
appear quick and smooth because, as the upper windows appeared first, the
underlying portions of the subsequently mapped/moved windows didn't need
to get drawn.

	Now, if you never have any overlapping windows on your desktop, you
won't see any improvement from this. If you only occasionally have a couple
of overlapping windows, you might not notice any difference. But if you have
several windows that overlap significantly, the transition to or from the
page where they are should be very noticeably quicker and smoother.




    There is one thing I would like to have done with this patch that I
simply didn't have time for. The original window chain really ought to be
closed into a ring, anchored at both ends on Scr.FvwmRoot, the way the new
stacking order chain is. This would eliminate the need to chase down the
chain to locate the last window: it would be readily addressable at all
times. Chain manipulation would be simpler and more consistent. However,
every bit of code that follows the window chain would have to be modified
to understand the new end-of-chain condition. Maybe one of these days....



		- RBW  05/15/1998

    -----------------------------------------------------------------------
    *  And, since the new chain is closed into a ring anchored at both ends
      on Scr.FvwmRoot, it can tell you who's third from the bottom as 
      quickly as who's third from the top.