I'm withdrawing my proposal for the GrabStateChange event

[Deron Johnson]

Hi Keith,

Yesterday we were discussing my proposal for adding a GrabStateChange
event to Xfixes. I'm going to withdraw this proposal (for now) because
I think I've thought of a good way get the information I need using
the existing X11 protocol.

My problems are solved by using special 3D proxy windows for active
grabs.  (If you recall, a 3D proxy window is a normal X11 InputOnly
window, which is never mapped, which are used in conjunction with 3D
grabs).  Whenever a 3D client actively grabs a 3D object I should use
a special "active" 3D proxy window to perform the corresponding X
active grab. The active 3D proxy window is unique to that 3D object
and I keep track of the mapping. When my Event Deliverer receives
Enter or FocusIn events with mode == NotifyGrab I will use this map on
the incoming window id to figure out the 3D grab object.

That leaves the issue of the default button grab and the fact that the
Enter-NotifyGrab event will come AFTER the button press in the event
stream (instead of before as with passive grabs). I don't want to
change the ordering of the existing X protocol event stream as you
suggested, because it has been this way for time immemorial. But it
turns out that a simple state machine on the client side is sufficient
to disambiguate the event stream.

So I'm going to withdraw my GrabStateChange event proposal for now and
prototype the above strategies. If I run into problems then I'll
reraise the issue down the road.