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: smarks@eng.sun.COM (Stuart Marks)
Subject: Re: OpenWindows button events question
Message-ID: <9104120322.AA15782@trantor.Eng.Sun.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
References: <9104112247.AA01067@lightning.McRCIM.McGill.EDU>
Date: 12 Apr 91 03:21:59 GMT
Lines: 52


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.