Newsgroups: comp.windows.x
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Subject: Re:  OpenWindows button events question
Message-ID: <9104112247.AA01067@lightning.McRCIM.McGill.EDU>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Date: 11 Apr 91 22:47:08 GMT
Lines: 50

> We have an application that does not run properly under open windows
> with "Click select: (click a mouse button in a window to give it the
> focus) enabled.  When we traced the events it is getting, it seems
> that when the left or middle mouse buttons are pressed over a window
> that currently has the input focus, the application in the window
> gets the sequence of events:

> LeaveNotify (leaving the window)
> ButtonPress (indicating the button)
> EnterNotify (entering the window)

> When the button is released, a simple button release event is generated

> The trouble is the application is confused by getting the button
> press when it thinks the mouse is not in the window.  The Leave and
> Enter events in this sequence do not make sense to me.  Are they a
> bug or a feature?  If they are a feature, could someone explain why
> they are sent when the mouse never leaves the window in question?

I don't know enough to say for sure, but look at the event structure
members that give more detail about the LeaveNotify and EnterNotify
events.  I suspect you are seeing olwm setting up passive grabs.  Then
when you press the button, the grab activates (generating the
LeaveNotify in the process, because the mouse is logically no longer in
the window).  olwm then decides the application should get the event,
so it does XAllowEvents(...,ReplayPointer,...), thus letting your
application see the event.  Then it ungrabs the pointer; when this
happens, you see the EnterNotify event, because the pointer is
logically re-entering your window.

The reason I said to look closely at the EnterNotify and LeaveNotify
events is that there is a member that indicates, among other things,
whether the event is due to a grab (de)activation.

This strikes me as a bad way of doing things.  It means that your
application does not have the automatic passive grab you normally would
for a button press, and it also generates this strange sequence of
events implying the mouse is not in the window when the press happens.
It seems to me that it would be better for olwm to set its passive grab
on the window manager parent windows for all applications *except* the
one which already has focus and therefore is supposed to see mouse
clicks.  Then when changing focus it should unset the passive grab on
the new focus window and add one for the old focus window.  This opens
up certain race conditions with mouse-ahead, but I consider them less
egregious than these problems.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu