Path: utzoo!attcan!uunet!husc6!ukma!tut.cis.ohio-state.edu!bloom-beacon!ZERMATT.LCS.MIT.EDU!RWS
From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler)
Newsgroups: comp.windows.x
Subject: Pointer/Button grabbing
Message-ID: <19880706132733.0.RWS@KILLINGTON.LCS.MIT.EDU>
Date: 6 Jul 88 13:27:00 GMT
References: <8807051536.AA00723@tub.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 34


    Date: Tue, 5 Jul 88 17:36:56 +0200
    From: Oliver Laumann 

    Is this a typical way XGrabButton() and XAllowEvents() are used?

For what you described, the Sync/AllowEvents didn't do you much good,
but you've got the basic idea.

    Can you briefly describe a scenario where XAllowEvents() is invoked
    with an event_mode other than AsyncPointer (i.e. SyncPointer or
    ReplayPointer)?

A window manager might want to use the first click of a button in a
window to set the input focus there, but still pass the click through
to the application; Replay can be used for that.

If one of the actions to be performed is to change the input focus, then
one would use Sync (both in the grab and in the AllowEvents) to freeze
input until you have a chance to actually move the input focus.
Depending on what your UI is, you may have to issue a GrabPointer during
the grab, to prevent the grab from being released prematurely.  For
example, if you want focus change to occur on release of the grabbed
button, Sync alone isn't sufficient, because the button release will
release the grab automatically.

    Is calling XGrabButton() with a pointer_mode of GrabModeAsync
    equivalent to calling it with a pointer_mode of GrabModeSync and
    when the first event arrives immediately invoking XAllowEvents()
    with an event_mode of AsyncPointer?

Not quite.  If you don't also freeze the keyboard, then with Sync,
keyboard events can come "out of sequence" from pointer events
until your AllowEvents is executed.