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

[Takuma Murakami <takuma at dgp dot ne dot jp>]

Earle,

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?

> Tamuka Murakami wrote...
> > Popups on a-o-t windows are having problems and should be fixed.
> > Did you fix it without reviving fAlwaysOnTop?  I'm interested in
> > the solution.
> 
> Yes, this does not require the flag.  Basically, any overridden window
> is now moved to the absolute top of the Z order, not just the top
> 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.

> > > > 1) Is minimization of a-o-t windows broken on release-59?
> > > > 2) Does the CVS build fix restacking problem?
> > Now it's quite clear to me, the culprit is my restacking bug.
> > If Earle's solution fixes #2, then it is what we've sought for.
> > Even if it doesn't fix it, he gives a nice stepping stone to
> > the final solution.  I'll look at the code for a while.
> 
> I'll have to read the archives some more to understand what
> you mean by the restacking bug, but FWIW there's a new
> function called PreserveWin32Stack in winmultiwindowwm.c which
> just walks the Win32 window stack after a map or a raise and
> forces the X stack to be in the same order.  It's implemented now
> just as a series of XRaiseWindows (it may be possible to use the
> X combined restacking function)...

In recent changes I made winRestackWindowMultiWindow empty
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).

Due to the changes propagation of Z order changes between X
and Windows were not correctly performed; that's the "restacking
bug" I've mentioned.

Takuma Murakami

Attachment: noaot.patch
Description: Binary data