Proposal for Version 0.4 of Xfixes Extension

[Deron Johnson]

Deron Johnson wrote On 01/23/06 14:30,:
> 
> 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.

Hi Keith,

I've implemented the window-tree scoped hide/show cursor proposal that
I sent out earlier. It follows the semantics you suggested.
Unfortunately, it turns out that the implementation is somewhat tricky.
Basically, what we want to do is to have CursorDisplayCursor display
a cursor with an empty image while the cursor is hidden. For example,
here is my code from xfixes/cursor.c:

static Bool
CursorDisplayCursor (ScreenPtr pScreen,
		     CursorPtr pCursor)
{
    CursorScreenPtr	cs = GetCursorScreen(pScreen);
    Bool		ret;

    Unwrap (cs, pScreen, DisplayCursor);

    if (cs->cursorIsHidden) {
	ret = (*pScreen->DisplayCursor) (pScreen, pInvisibleCursor);
    } else {
	ret = (*pScreen->DisplayCursor) (pScreen, pCursor);
    }
...

Unfortunately, this function does not have access to the current sprite
window. So it cannot check the window in this routine. We could add
a window argument to this routine, but that would change the established
DDX interface and mess up anybody who wraps or implements
pScreen->DisplayInterface.

To work around this, I made events.c:ChangeToCursor (and its counterpart
XineramaChangeToCursor) check the window and update a per-screen
"cursor hidden" status variable. Then I check this variable in
CursorDisplayCursor, as demonstrated in the above code.

Is this approach reasonable, or is there a better way to implement it?
Thanks.

	-Deron