>> | would be if it were possible to keep track of the stacking order
>> | without explicitly asking the X server with XQueryTree().
> I've been thinking about that a bit. Really keeping track of stacking
> order changes is quite difficult, given the various sorts of re-ordering
> that can take place on a ConfigureRequest.
FWIW, I have a patch that adds various "priority planes" (IOW, it
extends the notion of always-on-top), and for that it does keep track of
the stacking order (and incidentally uses this stacking order to do the
exact same map/unmap optimization).
I've been meaning to clean it up for inclusion for several years now,
but never got the motivation high enough to actually do it.
Side note: I've been running with this patch for too many years to
remember, and it includes an assertion test which compares the locally
managed stacking order with the one of XQueryTree, and although this
test is run very often, it doesn't seem to have a noticeable performance
impact, so maybe calling XQueryTree is not such a bad idea.
> One weird thing that I noticed is that if you re-start ctwm, then in
> some cases it will get the stacking order wrong the first time you visit
> any particular workspace. This becomes quite clear if you insert a
> "sleep(1);" call after Vanish() and DisplayWin(). The same wrong
> stacking order can be seen in the Workspace Manager's mini windows.
> Usually, once you visit the workspace this corrects itself. Sometimes it
> needs a random stacking order change before it is fixed. I'm not sure
> why this is.
I vaguely remember fixing a few stacking-order bugs as part of my
on-top-priority patch, so that might simply be it.
Stefan
