Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!apple!oliveb!orc!decwrl!wsl.dec.com!klee
From: klee@wsl.dec.com (Ken Lee)
Newsgroups: comp.windows.x
Subject: Re:  Button Press Events
Message-ID: <2796@bacchus.dec.com>
Date: 16 Feb 90 18:00:13 GMT
References: <9002160226.AA17976@Larry.McRCIM.McGill.EDU>
Sender: news@decwrl.dec.com
Reply-To: klee@decwrl.dec.com
Organization: DEC Western Software Laboratory
Lines: 27

In article <9002160226.AA17976@Larry.McRCIM.McGill.EDU>,
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes:
> (The reason behind this passive grab is not clear to me.  I see no
> particular benefit to it, and it does cause this peculiar restriction
> on ButtonPress event selection.)

I think the reason is that button presses are often used for dragging
(scroll bars, moving windows, etc.) or area selection operations
(selecting text, popup menus, etc.).  In these cases, you need the grab
to make sure the subsequent motion events and button release event go
to the right window.  Yes, you could do a separate button grab/ungrab,
but that's extra protocol, forces the client to select button release
events to ungrab, can cause timing problems (who grabs first?), and
will confuse beginning programmers who forget to ungrab.  There is
little penalty for programs not interested in the grab, since users
usually release right away in those cases.

The extra restrictions are unfortunate.  Perhaps there should be a
separate event for "button press without grab", but few clients want to
use this functionality.  One example of clients that dide was window
managers stealing buttons off of clients, but this was outlawed in the
latest ICCCCM.

Ken Lee
DEC Western Software Laboratory, Palo Alto, Calif.
Internet: klee@wsl.dec.com
uucp: uunet!decwrl!klee