[comp.windows.x] pointer button specific processing

robdu@syma.sussex.ac.uk (Robert James Duncan) (08/31/90)

when a pointer button is pressed in window W with no active pointer grab
in progress, the server searches the ancestors of W from the root down
looking for a passive grab.  if there isn't one, the server
automatically starts an active grab for the clients receiving the event.
this active grab is released when all the buttons are released.

why does it do this?

rob.
-- 
---------------------------------------------------------------
rob duncan, school of cognitive and computing sciences,
university of sussex, brighton, uk. robdu@cogs.susx.ac.uk
---------------------------------------------------------------

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/01/90)

    why does it do this?

Because it was felt that applications almost always want to see the
corresponding button release, even if it occurs outside their window.
Failing to receive the button release was a common cause of bugs in
X10 days.  In retrospect, explicit control over this behaviour would
probably have been better, but such is life.

mouse@LARRY.MCRCIM.MCGILL.EDU (09/02/90)

> when a pointer button is pressed in window W [with no explicit grabs
> present], the server automatically starts an active grab for the
> clients receiving the event.

Client, singular.  Because, you see, you can't have two clients
grabbing the pointer at the same time.

> why does it do this?

> From: rws@expo.lcs.mit.edu (Bob Scheifler)

> Because it was felt that applications almost always want to see the
> corresponding button release, even if it occurs outside their window.
> Failing to receive the button release was a common cause of bugs in
> X10 days.  In retrospect, explicit control over this behaviour would
> probably have been better, but such is life.

This would make a good R5 wish: a ButtonPressNoGrab event.  (I would
prefer ButtonPress and ButtonPressGrab, but that would be an
incompatible change.  Perhaps ButtonPressGrab and ButtonPressNoGrab,
with ButtonPress deprecated.)

Actually, I would prefer to fix the buggy clients rather than "fixing"
them by doing this to the server.  If the client misbehaves if it
doesn't see the release event, and it's too difficult to fix it, then
make it establish a passive grab; don't break ButtonPress events for
everybody else!  (As it stands, there's no way for more than one client
to receive button-down events, even though all[%] other event types can
be selected for by multiple clients.  Very ugly.  The "need" for seeing
the ButtonRelease event leads into the discussion of clicks as opposed
to presses and releases, which I won't go into here-&-now.)

[%] Almost all.  SubstructureRedirectMask is an (the?) exception,
    though even there I could probably make a case for allowing
    multiple clients to select for it, with careful specification of
    the resulting semantics.

					der Mouse

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