Proposal for Version 0.4 of Xfixes Extension

[Deron Johnson]

Keith Packard wrote On 01/19/06 18:44,:

> I think the grab stuff needs clarification, in particular, I'm assuming
> you intend for grabs within the entire hierarchy to cause an event to be
> delivered, not just for the particular window. That means a request on
> the root window would report any grab activating within the entire
> screen.

This was not my intention but it sounds like a good semantic.  I've
modified the text as follows:

"SelectGrabStateChangeInput is a request by which a client specifies
interest in receiving grab trigger and termination notification for a
window and its subwindows. If a grab triggers for one of these
windows, a GrabStateChange event with trigger==True will be sent to
interested clients. The window field will be set to the grab window.
If the grab that triggered was passive the type field will be set to
GrabTypePassive, otherwise it will be set to GrabTypeActive. If the
grab that triggered was specified by some client, the detail field
will be set to GrabDetailClient, otherwise it will be set to
GrabDetailDefault.

Likewise, when the grab terminates a GrabStateChange event with
trigger==False will be sent to clients interested in GrabStateChange
events for the grab window or one of its ancestors. The window field
will be set to the grab window, the type field will be set to
GrabTypeNone and the detail field will be set to GrabDetailNone.

...

SelectGrabStateChangeInput

	window:			Window
	event-mask:		SETofGRABSTATECHANGEEVENT

	This request tells the X server that the client is interested
        in receiving GrabStateChange events for the specified window
	and all of its subwindows."


> What about grabs on other screens? Do you hear about them too?

I don't think so. If a client is interested in receiving grab
notifications for other screens then it should register interest on the
root windows of the other screens.

> And, I was thinking that the HideCursor/ShowCursor stuff should be
> hierarchical as well; pass a window and have that cause the cursor to
> not be displayed within that window (or sub windows).

Yes. We could define it this way if you would like.

> With this, we
> again have the question about grabs, and I suggest that probably grabs
> within the hierarchy would respect the hide value while grabs outside
> would ignore it. I don't think this is terribly hard to implement; it's
> just a check up the tree for hide values each time the cursor enters
> another window or the pointer is grabbed.

I'll update the spec to include this and send it out for review.

> Also left undefined is the behaviour when multiple clients make this
> request. I suggest that the effect should be cumulative. 

What do you mean by "cumulative?" Do you mean that the cursor should be
hidden for a window as long as one or more clients have specified that
it should be hidden? If so, we can use simple reference counting to
implement this.

> Also, the effect of any calls to HideCursor should be voided when the
> resources for the client are destroyed (which tracks client closure,
> except when resources are retained).

I agree.