"Michael_K._Powers.WBST139"@Xerox.COM (01/08/88)
That clears up some of my questions about the grabbing the pointer but I am still unclear at how to approach what my application requires. Perhaps a better example: I have a window(A) that is 640x350 mapped to root. I have another window(B) which is a child of A and is also 640x350. It is mapped to A and covers it. B Contains mutiple windows that represent checkbox buttons, text, etc. All the windows are set to no_propagate for all events. The reason for this is that we don't want a button press on a checkbox button, even if it doesn't care about it, to fall through to a button it occludes. So this is the basic setup. Now I want to temporarily ask for a button down event anywhere on the area defined by window A ignoring any siblings request for said event. Once I get the button down (I want to ignore the release) I wish to take that point and use it for the stake point of a rubberbanding line. I then wish to grab, for the area defined by A, all motion and button down events. The track point of the line will follow the pointer. Then when another button down is recieved the rubber line is done and things, event-wise, should return to the way they were before the first down event. A question at this point. Why should this require me to grab the device for the entire display? Basically what I have here is a microcosm display that doesn't really want to stop the user from moving to another client application window just because it wants to rubberband a line. (or bring up a menu) GrabButton does more of what I need except that it assumes you want to grab the pointer inbetween a down and up event. Am I using the propagate wrong? Is this style of real-estate tracking "not recommended"? -mike powers.wbst139@Xerox.com
oj@apollo.uucp (Ellis Oliver Jones) (01/08/88)
In article <880107-095710-7037@Xerox> "Michael_K._Powers.WBST139"@Xerox.COM writes: >...Now I want to temporarily ask for a button down >event anywhere on the area defined by window A... I do this as follows: (a) creating an InputOnly window (sibling or child to A) the size of A (this is a "transient" window as far as any WM is concerned) (b) doing a MapRaised of the InputOnly window when I'm ready to start the "drag" mode you mentioned. (c) Accepting ButtonPress, ButtonRelease and MotionNotify events from the InputOnly window. (d) Do any echoing to window A with GXxor and IncludeInferiors (e) When I get the ButtonRelease (or otherwise get done with this operational mode), I unmap and destroy the InputOnly window (the easy way of dealing with the possibility that A will get resized by the WM). This works well. It also gives me a decent way to change the cursor (make a different one for the InputOnly window) to show the user that she's dropped into this mode. You might also try XGrabButton requests (for all the buttons, I guess; you weren't clear as to whether it was just one button that worked this way) in Window A. Specify a owner_events parameter of False. Then when the user presses any button, you'll start an active grab within window A, and you'll get all the events from Window A. Should work. /oj
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (01/20/88)
Sender: Michael_K._Powers.WBST139@Xerox.COM
Date: Thu, 7 Jan 88 12:56 EST
Now I want to temporarily ask for a button down
event anywhere on the area defined by window A ignoring any siblings request for
said event. Once I get the button down (I want to ignore the release) I wish to
take that point and use it for the stake point of a rubberbanding line. I then
wish to grab, for the area defined by A, all motion and button down events. The
track point of the line will follow the pointer. Then when another button down
is recieved the rubber line is done and things, event-wise, should return to the
way they were before the first down event.
The key thing here is that you want to ignore what your subwindows are
asking for. Had you brought this up about a year ago, and got me
thinking in the same direction, I would have suggested that perhaps the
right thing would be to add a new window attribute
do-not-descend: SETofDEVICEEVENT
that was like the opposite of do-not-propagate, i.e., have the server
walk down the tree first to figure out where the effective "source"
window for the event was, stopping at the first window with a matching
do-not-descend. For your scenario, you could then simply turn Button
related events on and off in this mask on window A. Even though it is
too late for 11.0, it still seems like an idea worth someone fleshing
out (there are lots of interactions with other mechanisms that need to
be considered).
As it is, your choices seem limited to grabbing the pointer (which is
inconsiderate of other applications, I agree) or getting whatever
toolkit layer or widgets you are using to cooperate in within-client
transformation of the events, to have them automatically propagated up
the widget hierarchy (with coordinates appropriately massaged) to the
desired parent.