public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
* Re: Minimising window with "Always on top" attribute leaves contents in underlying window
[not found] <MABBIGKNNKPOMNLEJIGHKEBNCCAA.mikethepsych@blueyonder.co.uk >
@ 2004-01-26 4:08 ` Earle F. Philhower III
0 siblings, 0 replies; 6+ messages in thread
From: Earle F. Philhower III @ 2004-01-26 4:08 UTC (permalink / raw)
To: cygwin-xfree
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
Hi Mike...
At 08:29 AM 1/25/2004 +0000, Mike wrote:
>I'm using 4.3.0-42 and have noticed that the following minor bug in
>multi-window operation when running on Win2K and WinXPPro:
>Two windows (terminal or otherwise) are overlapped and the topmost one has
>it's "Always on top" attribute set (by right-clicking on the windows title
>bar). The topmost window is then minimised, leaving a copy of its contents
>on the desktop, viewable by moving the remaining window over the portion of
>the desktop previously occupied by the other window.
It's been a while since I submitted a patch, but since this problem
is due to my code I'll be nice and fix it. Basically, whenever we get
a WM_SYSCOMMAND:SC_MINIMIZE we need to disable the HWND_TOPMOST attribute
and let the X system recognize it. On a WM_SYSCOMMAND:SC_RESTORE we just
need to reset that attribute to what it was before.
I'm attaching a patch *against the CVS -r CYGWIN tree* because I cannot
get the XWin-4.3.0-42 source available on
http://xfree86.cygwin.com/devel/server/changelog.html
to compile properly, whereas the freedesktop CVS goes thru without a hitch.
It adds a boolean fAlwaysOnTop to the window privates; caches the AOT value
on a WM_SYSCOMMAND:SC_MINIMIZE and removes top-z attributes from the window;
restores the AOT value on a WM_SYSCOMMAND:SC_RESTORE; and changes the
WM_WINDOWPOSCHANGED event handler to always allow the Windoze DefWindowProc()
to be called (necessary for the changes I did, and doesn't seem to have any
negative effects).
-Earle F. Philhower, III
earle@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
[-- Attachment #2: fixaot.patch --]
[-- Type: application/octet-stream, Size: 1913 bytes --]
diff -U3 xwin.cvs/winmultiwindowwindow.c xwin/winmultiwindowwindow.c
--- xwin.cvs/winmultiwindowwindow.c 2004-01-25 19:04:11.578125000 -0800
+++ xwin/winmultiwindowwindow.c 2004-01-25 19:30:38.218750000 -0800
@@ -105,7 +105,8 @@
pWinPriv->pScreenPriv = winGetScreenPriv(pWin->drawable.pScreen);
pWinPriv->fXKilled = FALSE;
pWinPriv->fNeedRestore = FALSE;
-
+ pWinPriv->fAlwaysOnTop = FALSE;
+
return fResult;
}
diff -U3 xwin.cvs/winmultiwindowwndproc.c xwin/winmultiwindowwndproc.c
--- xwin.cvs/winmultiwindowwndproc.c 2004-01-25 19:04:11.609375000 -0800
+++ xwin/winmultiwindowwndproc.c 2004-01-25 19:55:45.859375000 -0800
@@ -387,6 +387,22 @@
/*
* Any window menu items go through here
*/
+ /* If minimizing then remove always-on-top, and store the setting */
+ if (wParam == SC_MINIMIZE)
+ {
+ if (GetWindowLong (hwnd, GWL_EXSTYLE) & WS_EX_TOPMOST)
+ pWinPriv->fAlwaysOnTop = TRUE;
+ else
+ pWinPriv->fAlwaysOnTop = FALSE;
+ SetWindowPos(hwnd, HWND_BOTTOM, 0, 0, 0, 0,
+ SWP_NOMOVE|SWP_NOSIZE);
+ }
+ else if (wParam == SC_RESTORE)
+ {
+ if (pWinPriv->fAlwaysOnTop)
+ SetWindowPos(hwnd, HWND_TOPMOST, 0, 0, 0, 0,
+ SWP_NOMOVE|SWP_NOSIZE);
+ }
HandleCustomWM_COMMAND ((unsigned long)hwnd, LOWORD(wParam));
break;
@@ -893,7 +909,7 @@
if (s_pScreenPriv != NULL)
s_pScreenPriv->fWindowOrderChanged = TRUE;
}
- return 0;
+ break;
case WM_SIZE:
/* see dix/window.c */
diff -U3 xwin.cvs/winwindow.h xwin/winwindow.h
--- xwin.cvs/winwindow.h 2004-01-25 19:04:12.187500000 -0800
+++ xwin/winwindow.h 2004-01-25 19:06:40.281250000 -0800
@@ -75,6 +75,7 @@
Bool fXKilled;
Bool fNeedRestore;
POINT ptRestore;
+ Bool fAlwaysOnTop;
/* Privates used by primary fb DirectDraw server */
LPDDSURFACEDESC pddsdPrimary;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Minimising window with "Always on top" attribute leaves contents in underlying window
2004-01-26 4:37 Harold L Hunt II
@ 2004-01-26 5:10 ` Earle F. Philhower III
0 siblings, 0 replies; 6+ messages in thread
From: Earle F. Philhower III @ 2004-01-26 5:10 UTC (permalink / raw)
To: cygwin-xfree
Howdy Harold, I thought you were taking it easy for a while!
At 11:37 PM 1/25/2004 -0500, you wrote:
>Any reason for the following in your patch:
>@@ -893,7 +909,7 @@
> if (s_pScreenPriv != NULL)
> s_pScreenPriv->fWindowOrderChanged = TRUE;
> }
>- return 0;
>+ break;
>The thing that strikes me as odd is that you have to return from the
>WM_WINDOWPOSCHANGED message without calling DefWindowProc (which will get
>called if you change that return to a break) in order to prevent Windows
>from breaking that message down into a WM_SIZE and WM_MOVE message and
>sending those in addition. My worry is that you may have essentially
>found a bug in the WM_WINDOWPOSCHANGED handling that was fixed by allowing
>the WM_SIZE and WM_MOVE messages to be generated and handled, when we
>should really fix such a bug instead of accidentally masking its existance.
>I'm not comfortable removing this change from your patch since it will
>then need to be tested again to verify that things work as expected. Since
>you have already been testing it, I figured it would be easier for you to
>do the testing :)
I did extensive testing without that change, actually, because it
took me a while to figure out why the minimize button and sysmenus
worked but the taskbar left-click 2x didn't. ;)
You can remove it, but minimizing the window by 2x-clicking on the
Windows taskbar won't propagate the Z order change w/the same
messages as if you were to use the system menu or the minimize
button. Why? AFAICT the minimize button or menu item send a wm-move,
even if you don't let DefWindowProc() do its thing. I suspect
Explorer sends its own messages when you click on the taskbar,
and they are not the same as the frame WndProc()'s.
FWIW I can't really see any reason not to allow DefWindowProc to have
a shot at the WM_WINDOWPOSCHANGED message, but I'll admit that I've
not gone through all of Kensuke's code...
-Earle F. Philhower, III
earle@ziplabel.com
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Minimising window with "Always on top" attribute leaves contents in underlying window
@ 2004-01-26 4:37 Harold L Hunt II
2004-01-26 5:10 ` Earle F. Philhower III
0 siblings, 1 reply; 6+ messages in thread
From: Harold L Hunt II @ 2004-01-26 4:37 UTC (permalink / raw)
To: cygx
Earle,
Any reason for the following in your patch:
@@ -893,7 +909,7 @@
if (s_pScreenPriv != NULL)
s_pScreenPriv->fWindowOrderChanged = TRUE;
}
- return 0;
+ break;
The thing that strikes me as odd is that you have to return from the
WM_WINDOWPOSCHANGED message without calling DefWindowProc (which will
get called if you change that return to a break) in order to prevent
Windows from breaking that message down into a WM_SIZE and WM_MOVE
message and sending those in addition. My worry is that you may have
essentially found a bug in the WM_WINDOWPOSCHANGED handling that was
fixed by allowing the WM_SIZE and WM_MOVE messages to be generated and
handled, when we should really fix such a bug instead of accidentally
masking its existance.
I'm not comfortable removing this change from your patch since it will
then need to be tested again to verify that things work as expected.
Since you have already been testing it, I figured it would be easier for
you to do the testing :)
Let me know what to do with your patch,
Harold
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Minimising window with "Always on top" attribute leaves contents in underlying window
2004-01-25 18:39 ` Jack Tanner
@ 2004-01-25 19:58 ` Jack Tanner
0 siblings, 0 replies; 6+ messages in thread
From: Jack Tanner @ 2004-01-25 19:58 UTC (permalink / raw)
To: cygwin-xfree
This is probably related: using multi-window mode, open an emacs over
ssh. Click on a menu (e.g, "File"), leave it droppped down, and minimize
the emacs window. Result: emacs gets minimized, but the dropped down
menu stays behind.
-JT
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Minimising window with "Always on top" attribute leaves contents in underlying window
2004-01-25 8:29 Mike Parker
@ 2004-01-25 18:39 ` Jack Tanner
2004-01-25 19:58 ` Jack Tanner
0 siblings, 1 reply; 6+ messages in thread
From: Jack Tanner @ 2004-01-25 18:39 UTC (permalink / raw)
To: cygwin-xfree
Mike Parker wrote:
> I'm using 4.3.0-42 and have noticed that the following minor bug in
> multi-window operation when running on Win2K and WinXPPro:
>
> Two windows (terminal or otherwise) are overlapped and the topmost one has
> it's "Always on top" attribute set (by right-clicking on the windows title
> bar). The topmost window is then minimised, leaving a copy of its contents
> on the desktop, viewable by moving the remaining window over the portion of
> the desktop previously occupied by the other window.
Confirmed.
Does anyone know how other window managers usually handle the
always-on-top-then-minimized use case?
-JT
^ permalink raw reply [flat|nested] 6+ messages in thread
* Minimising window with "Always on top" attribute leaves contents in underlying window
@ 2004-01-25 8:29 Mike Parker
2004-01-25 18:39 ` Jack Tanner
0 siblings, 1 reply; 6+ messages in thread
From: Mike Parker @ 2004-01-25 8:29 UTC (permalink / raw)
To: cygwin-xfree
I'm using 4.3.0-42 and have noticed that the following minor bug in
multi-window operation when running on Win2K and WinXPPro:
Two windows (terminal or otherwise) are overlapped and the topmost one has
it's "Always on top" attribute set (by right-clicking on the windows title
bar). The topmost window is then minimised, leaving a copy of its contents
on the desktop, viewable by moving the remaining window over the portion of
the desktop previously occupied by the other window.
Regards,
Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-01-26 5:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <MABBIGKNNKPOMNLEJIGHKEBNCCAA.mikethepsych@blueyonder.co.uk >
2004-01-26 4:08 ` Minimising window with "Always on top" attribute leaves contents in underlying window Earle F. Philhower III
2004-01-26 4:37 Harold L Hunt II
2004-01-26 5:10 ` Earle F. Philhower III
-- strict thread matches above, loose matches on Subject: below --
2004-01-25 8:29 Mike Parker
2004-01-25 18:39 ` Jack Tanner
2004-01-25 19:58 ` Jack Tanner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).