Re: Pointer hooks

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 2 Jul 2001, Owen Taylor wrote:
> 
> > 
> > This look like what you want for '56914 Add virtualization of XQueryPointer'?
> > 
> > I haven't actually tried running it yet, but it compiles, and I
> > don't think there is a whole lot I could have gotten wrong here.
> 
> jup, i think so, so far gerd-xwrapper.c only had to intercept
> XQueryPointer().
> however, grepping through the gdk sources, we also use XQueryPointer() in
> void
> handle_motion_notify(XDeviceMotionEvent *event)
> { ... }
> 
> i'm not sure how that correlates, since i don't know when that function
> is actually triggered and why it doesn't have a gdk_ prefix.

gxid.c - relic of my early days of GTK+ programming - if you
comile with --with-xinput=gxi, then it builds and installs
a little daemon "gxid" that does switching of XInput devices ...
I've left it there since it might be useful for people
trying to use XInput on non-XFree86, but I've never gotten
a report of anyone successfully doing so.

Anyways, not relevant in this context.
 
> of course this virtualization stuff will only work:
> - if we don't add XQueryPointer() to other (newly introduced) gdk functions
>   during a stable release (for devel we could virtualize such a function
>   as well then)

Well, we'd probably be able to write those in terms of 
gdk_window_get_pointer(), most of the time. If we wrote
it as "gdk_set_get_pointer_func(), gdk_set_window_at_pointer_func()",
we'd have more flexibility, of course. The vtable isn't 
expandable. 

(The way of allowing the vtable to be expandable without
breaking bin compat is to have gdk_pointer_hooks_new()/free(),
and have code to do fallbacks for NULL pointers in the
table, and only extend at the end. This seems like more
complexity than it's really worth.)

> - if XQueryPointer() is indeed the only thing that X offers to query current
>   state (though it looks like this as all other things are delivered per
>   events)

The drag-and-drop code does extensive caching of the position /
stacking order of  windows on the root window, but there are
lots of other reasons why using something like GERD with the
DND code isn't going to work.... 

Also, the support for resize grips (gdk_window_being_move/begin_resize())
isn't going to work at all with GERD, since it does the event
handling at the GDK layer, not in GTK+.

If you want to be able to record things like DND, then I think
the better approach is:

 - Record globally, using the XRecord extension
 - Playback using XTest
 - Use a small GTK+ module to allow the global record/playback
   feature to query and track the widget heirarchy, so that it can
   be more robust about playing back events in the same semantic
   place rather than the same physical place.

You might also need some window manager integration here as
well... you're really better off for robustness (or at least
appearance) if you can always place windows in the same location 
as their original location.

> with this virtualization, GERD should become gdk-backend independant, which
> would actually be pretty cool.

I'm _not_ adding gdk_pointer_warp() ... ;-)

My opinion 

                                        Owen