warren@cbnewsh.att.com (warren.a.montgomery) (04/04/91)
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? -- Warren Montgomery att!ihlpf!warren
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (04/12/91)
> 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
smarks@eng.sun.COM (Stuart Marks) (04/12/91)
der Mouse <mouse@lightning.mcrcim.mcgill.edu> writes: > LeaveNotify (leaving the window) > ButtonPress (indicating the button) > EnterNotify (entering the window) 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. Yes, this is a pretty good description of what is going on. 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, Nope. The semantics of AllowEvents(ReplayPointer) are that windows further down in the hierarchy can also have passive grabs activated. and it also generates this strange sequence of events implying the mouse is not in the window when the press happens. The sequence if events is indeed strange. As you mention above, there is enough information in the events for the program to disambiguate them. 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. Since the problems you raised are non-problems, I disagree. s'marks Stuart W. Marks ARPA: smarks@eng.sun.com Windows & Graphics Software UUCP: sun!smarks Sun Microsystems, Inc.
nazgul@alphalpha.com (Kee Hinckley) (04/13/91)
>> 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 This is probably related to the multitude of problems I see under Olwm. Things like clicking in one window and having the event go to the previous window. Or clicking in a Motif text widget and watching it select everything between where I was the last time I used it and where I just clicked (but only briefly, it then gets unselected - but god forbid you started typing - pending delete will nuke it). -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (04/13/91)
>> 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, > Nope. The semantics of AllowEvents(ReplayPointer) are that windows > further down in the hierarchy can also have passive grabs activated. The order of the ButtonPress and EnterNotify events implies that the reprocessing is happening before olwm's grab is being released. Does this then imply that there can be two pointer grabs active at once? (The not-yet-released WM grab and the client's grab, either explicit or by default on a button press). Surely not. >> and it also generates this strange sequence of events implying the >> mouse is not in the window when the press happens. > The sequence if events is indeed strange. As you mention above, > there is enough information in the events for the program to > disambiguate them. This is a lesser complaint; that's why I put it second. As you say, it's not serious, but it really shouldn't be necessary. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
Stuart.Marks@eng.sun.COM (Stuart Marks) (04/17/91)
>> der Mouse: >> 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, > smarks: > Nope. The semantics of AllowEvents(ReplayPointer) are that windows > further down in the hierarchy can also have passive grabs activated. der Mouse: The order of the ButtonPress and EnterNotify events implies that the reprocessing is happening before olwm's grab is being released. Does this then imply that there can be two pointer grabs active at once? No. The event sequence from the OpenWindows version 2 server is actually incorrect, which adds to the confusion. The (buggy) event sequence is: LeaveNotify(mode=Grab) ButtonPress EnterNotify(mode=Grab) Even though the event sequence is screwed up, passive grabs on windows further down in the hierarchy are getting activated properly. The correct event sequence is: LeaveNotify(mode=Grab) EnterNotify(mode=Ungrab) ButtonPress >> and it also generates this strange sequence of events implying the >> mouse is not in the window when the press happens. > The sequence if events is indeed strange. As you mention above, > there is enough information in the events for the program to > disambiguate them. This is a lesser complaint; that's why I put it second. As you say, it's not serious, but it really shouldn't be necessary. It might not be necessary in this case. However, in general -- and in the absence of a buggy server -- it is still sometimes necessary for clients to pay attention to the information in the mode field. If the client is (for example) painting a crosshair, it will probably want to disregard Enter and Leave events generated by grabs. s'marks Stuart W. Marks ARPA: smarks@eng.sun.com Windows & Graphics Software UUCP: sun!smarks Sun Microsystems, Inc.
nazgul@alphalpha.com (Kee Hinckley) (04/17/91)
In article <9104162044.AA27125@trantor.Eng.Sun.COM> Stuart.Marks@eng.sun.COM (Stuart Marks) writes: >No. The event sequence from the OpenWindows version 2 server is actually >incorrect, which adds to the confusion. The (buggy) event sequence is: > > LeaveNotify(mode=Grab) > ButtonPress > EnterNotify(mode=Grab) ... >It might not be necessary in this case. However, in general -- and in the >absence of a buggy server -- it is still sometimes necessary for clients to >pay attention to the information in the mode field. If the client is (for >example) painting a crosshair, it will probably want to disregard Enter and >Leave events generated by grabs. > >s'marks > >Stuart W. Marks ARPA: smarks@eng.sun.com >Windows & Graphics Software UUCP: sun!smarks >Sun Microsystems, Inc. I posted this here, and I've posted it to comp.windows.open-look. Let me try again. I believe that this problem is directly responsible for the misbehavior of my application under OW2.0. In particular I am getting *lots* of situations where button clicks are being delivered to the last item I clicked on rather than the item I just clicked on. This situation can be fatal to the user (click on a delete button, go somewhere else, click, and it deletes again). Is there anyway my application can work around this problem? Maybe by intercepting events and inserting some synthetic ones? Barring that. When will OW2.0 be fixed? -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.