karlton@DECWRL.DEC.COM.UUCP (10/30/87)
>"at most one client at a time can select for ... ButtonPressMask"
The restriction is on a per window basis. The hint is that the paragraph in
which the above occurs starts "Multiple clients can select input on the same
window."
PKRWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (10/30/87)
Date: 29 Oct 87 19:23:03 GMT
From: hplabsz!dayoung@hplabs.hp.com (Doug A. Young)
"at most one client at a time can select for ... ButtonPressMask"
As the start of that Xlib paragraph tried to indicate, this is a
restriction on any given window, not on the entire collection of
windows. The restriction is that on a given window, two independent
clients cannot both select for ButtonPressMask (because the button press
initiates a grab, and it wouldn't be obvious which client should be the
grabber).Brian.Ebert@transam.ece.cmu.EDU (02/16/90)
Can someone please mail or post the reason only one client is allowed to receive a window's button events while more than one can receive key and expose events? Curious.
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (02/16/90)
> Can someone please mail or post the reason only one client is allowed > to receive a window's button events while more than one can receive > key and expose events? Curious. That had me baffled for a while too. However, if you read the doc carefully, you'll find that pressing a button starts a passive grab. The limitation to one client sidesteps the question of in which client's name this grab is started. (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.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
klee@wsl.dec.com (Ken Lee) (02/17/90)
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
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (02/20/90)
[ >> = me, > = Ken Lee ] >> (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.) > 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. Few clients want SubstructureRedirectMask either. Shall we get rid of it too? Like SubstructureRedirectMask, button-press-without-grab event mask functionality can't be faked with the existing tools (as far as I can see - am I missing something obvious?). So, even if fairly few clients want it, I think it should be provided. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu (Of course, there are lots of other things that I think should be provided....)