Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!ucsd!ucbvax!bloom-beacon!LIGHTNING.MCRCIM.MCGILL.EDU!mouse
From: mouse@LIGHTNING.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  XSendEvent question
Message-ID: <9011081402.AA04886@lightning.McRCIM.McGill.EDU>
Date: 8 Nov 90 14:02:28 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 82

> I am currently working on an application (a modified `twm' to be
> exact) that allows for a certain amount of `remote control' of X11
> applications.  Once a common application has been determined, a
> controlling user's host replicates the pertinent X11 events to all
> the listening hosts.  All event delivery to the selected application
> is done via calls to XSendEvent().

Note that not all applications listen to events sent with XSendEvent.
(Not that I'm saying this is your problem; see below.)

> The event capture is done by creating an InputOnly `capture window'
> whose parent is the selected application (target) window and whose
> event mask has all bits set, except `PointerMotionHintMask'.

> Currently, the application *does* work for client applications that
> have a *single* X11 window, but I have been unable to deliver the
> events to *multiple* window applications (e.g. xcalc or xwebster).

Well, I think I can perhaps explain the flaw.  Suppose we have an
application whose window structure is

toplevel
    menu
	button 1
	button 2
	button 3
	button 4
    main graphics window

Now, you add your blanket InputOnly window:

toplevel
    blanket
    menu
	button 1
	button 2
	button 3
	button 4
    main graphics window

This is perhaps not a great idea.  Why?

- This breaks if the application has set different pointer cursors on
  its various windows, because the pointer cursor will always be that
  of your blanket window.

- The application may raise children of its main window with
  XRaiseWindow or equivalent; this will unexpectedly put them in front
  of your blanket.

- If the application grabs the pointer, you lose your control.

Similar problems exist for keyboard events, but let's not get into that.

But let's ignore possible problems like those for the moment.

Now, suppose the user puts the cursor over "button 1" and clicks a
button.  If it weren't for your blanket, the application would see a
ButtonPress event generated on the "button 1" window.  (Depending on
the event masks, it might be received through the "menu" or "toplevel"
windows, but the "event window" will be the "button 1" window.)  But
your blanket window is present, so the event window of the generated
event is "blanket".  Your program receives the event and sends it to
"toplevel" with XSendEvent.  If the application ignores ButtonPress
events on "toplevel", expecting to receive them through "button 1" or
"menu" instead, it won't see it at all.  If it does see it, it will
have no way of telling that the click was "over" button 1; instead, the
event window will be a window it's never heard of and has no idea how
to deal with.  It will probably drop the event on the floor.

Either way, it doesn't work right.

In order to do this right, you will need to duplicate the whole window
tree in a shadow tree of InputOnly windows, select for ConfigureNotify
and StructureNotify (or perhaps SubstructureNotify) on the
application's windows, and keep the window trees in sync (and there
will always be race conditions).

					der Mouse

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