This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
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...)
> 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
(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!
-Earle F. Philhower, III
earle@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com