Re: Changes to multiwindow mode and always-on-top (ping Takuma)

[Harold L Hunt II <huntharo at msu dot edu>]

Earle,

Earle F. Philhower III wrote:
> Hello Takuma,
>
> At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote:
>
> > You give me a good insight to improve Z order handling.
> > I believe we can approach to better solutions.  The attached
> > is my latest code which should fix all problems on restacking
> > and a-o-t windows without using fAlwaysOnTop flag.  Could you
> > try and review this?
>
>
> It works great from my testing today!  On Monday I'll bring it to
> work for a harder test, I normally have 10 or so emacs and xterms
> running with an occasional EDA tool.  (It seems that cygwin's
> emacs-x11 has some problems, not due to these changes, so I can't
> get too many started locally to test...)

I haven't gotten a chance to test Takuma's new patch yet, so I was 
wondering if you have checked what happens when you open two xterms, 
place a Cygwin bash shell inbetween them in the Z order partially 
overlapping with both of them, then minimize one xterm and then the 
Cygwin bash shell... you'll have to play with the ordering a little bit, 
but see if you can get it to have one xterm showing the contents of the 
other xterm where they were previously overlapping.  That was a bug that 
we have had before and Takuma's changes from last week re-introduced 
that bug.  I'm not sure if his new patch was an attempt to fix that or 
not... but this is something that somebody will need to fix and I'd 
appreciate it if you had some insight if this is not already fixed.

> > and removed winReorderWindowsMultiWindow(), which were my
> > fault and forced you to reinvent PreserveWin32Stack().  I think
> > winReorderWindowsMultiWindow() is Kensuke's version of
> > PreserveWin32Stack().  He does the work in X server's internal
> > function (ConfigureWindow) while you do through WM thread
> > (XRaiseWindow).
>
>
> Yes, I'm more familiar with Xlib than internal DDX routines,
> so chose the one I understood.  The restacking you've put
> back in the ReorderMW works just as well, or probably better.
>
> One thing I was worried about, and I see that you've taken care
> of, is the fact that since we iterate over the Win32 window stack
> and do a series of ConfigureWindow/etc., those ConfigureWindows()
> might cause yet another Restack call, resulting in up to ((n*(n-1))/2)
> calls.  The fRestacking flag you put back in looks like the easiest
> way of handling this...
>
> Thanks, I'll let you know if anything pops up in my testing!

Glad to know that you guys are looking at this in depth.  :)

Harold