Changes to multiwindow mode and always-on-top (ping Takuma)
Earle F. Philhower III
Sat Mar 20 22:32:00 GMT 2004
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...)
> > of the regular stack. It's a 1 line change in winmultiwindowwndproc.c.
>It must be the SetWindowPos() in the winTopLevelWindowProc's
>WM_SHOWWINDOW handler. I removed SWP_NOACTIVATE flag since
>popups can't get into the front with the flag.
Yes, seems fine w/o that flag set. The HWND_TOPMOST still gets set
fine, and menus stay in the top z-pane. I just put it in there
because during some intermediate testings I left all created windows
as OVERLAPPEDWINDOW and not set back to POPUP (for the cascading).
>In recent changes I made winRestackWindowMultiWindow empty
I was wondering about the #if 0 on this section, but your new
reorder routine seems to keep things working 100%.
>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
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!
-Earle F. Philhower, III
cdrlabel - ZipLabel - FlpLabel
More information about the Cygwin-xfree