This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
RE: [PATCH] RE: Ghost cursors (was: RE: alt-tab: client window receives tab / pressing both...)
- From: "Harold Hunt" <huntharo at msu dot edu>
- To: "cygx" <cygwin-xfree at cygwin dot com>
- Date: Thu, 13 Jun 2002 03:19:18 -0400
- Subject: RE: [PATCH] RE: Ghost cursors (was: RE: alt-tab: client window receives tab / pressing both...)
Nevermind, I just implemented the patch that I was talking about below.
However, I'm getting a strange problem where if I pass any 0 argument
parameters (e.g. -lesspointer) to XWin.exe and I start with 'start XWin' on
Windows 2000 then my log file only contains two lines:
ddxProcessArgument () - Initializing default screens
winInitializeDefaultScreens () - w 1024 h 768
If I start with 'start /B XWin' then the log is normal. I don't understand
what is going on here.
Maybe I've just done too many compiles and I need to restart my computer.
Or maybe I need to go to bed...
Harold
> -----Original Message-----
> From: cygwin-xfree-owner@cygwin.com
> [mailto:cygwin-xfree-owner@cygwin.com]On Behalf Of Harold Hunt
> Sent: Thursday, June 13, 2002 2:15 AM
> To: cygx
> Subject: RE: [PATCH] RE: Ghost cursors (was: RE: alt-tab: client window
> receives tab / pressing both...)
>
>
> Stuart,
>
> Naturally, now that I have applied the -lesspointer patch I have
> remembered
> why we switched away from hiding the Windows mouse cursor when we were
> inactive. The reason goes like this:
>
> 1) User has a Cygwin/XFree86 window that is away from the task bar.
>
> 2) User activates the Cygwin/XFree86 window to bring it to the top, though
> the window is small (say 640x480 on a 1024x768 screen) so it doesn't cover
> all other windows.
>
> 3) Now the user activates another application via the taskbar,
> say a Cygwin
> bash shell. This other application does not completely cover the
> Cygwin/XFree86 window.
>
> 4) The user moves the mouse into the Cygwin/XFree86 window, without
> clicking, thus hiding the mouse cursor but not activating the
> Cygwin/XFree86
> window.
>
> 5) A popup window from another application grabs the focus and either the
> popup window covers the area underneath the mouse or the user moves the
> mouse into the popup window in such a way as to not cross the non-client
> area of the Cygwin/XFree86 window.
>
> 6) At this point Cygwin/XFree86 should no longer be hiding the
> mouse cursor
> because a) we aren't active and b) the mouse cursor is not over
> our window.
> However, our only way of detecting that the mouse pointer has left our
> window when we are inactive is to watch for the non-client area mouse
> messages. In this test case we never see a non-client area mouse
> message so
> we never show the cursor.
>
>
> I can't remember if this actually causes the Windows cursor to
> not be shown
> for the popup window or not. It may depend entirely on the version of
> Windows, or it may depend on the popup window, etc.
>
> All I can say is that the -lesspointer parameter is your guy's
> baby and I'll
> send people to you if they complain about -lesspointer causing
> their cursor
> to disappear over other Windows windows. :)
>
> I think the very simple method to make -lesspointer more robust is to call
> TrackMouseEvent with the TME_LEAVE flag when we get our first client area
> mouse message. Then when the mouse leaves our client area (and
> I'm assuming
> that a popup covering the area underneath the mouse qualifies as
> leaving the
> client area) we will get a WM_MOUSELEAVE message. We can simply show the
> Windows mouse cursor if it is being hidden at that time. Simple, eh?
>
>
> Harold
>