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