Re: gdk_window_at_pointer and foreign windows

["Kevin O'Riordan" <k oriordan gmail com>]

On 2/20/07, Brian J. Tarricone <bjt23 cornell edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 20 Feb 2007 11:37:59 +0000 Kevin O'Riordan wrote:
>
> > Thanks for the reply. I was helping someone look at a problem they
> > were having with embedding a native application in the Eclipse
> > framework on Linux/GTK. It works fine for the most part (using
> > GtkSocket to reparent native application windows to the SWT control
> > for the view), there's just a minor problem where dragging views over
> > the native application view behaves as if you were dragging views
> > outside the Eclipse window. I traced it down to the
> > OS.gdk_window_at_pointer call returning 0 rather than the window
> > handle when the mouse is over the native application view.
>
> This is somewhat messy, but you could check for a NULL return to
> gdk_window_at_pointer(), and then use XQueryTree() on the toplevel
> window (the one that you used gdk_window_foreign_new() on) to find all
> the children of that window, and call gdk_window_foreign_new() on those
> as well.  At least that way gdk will always be able to see them.  There
> might be a way to grab new X windows as they appear as well, but I'm
> not sure about that without digging a bit deeper.
>
>         -brian

It would require a patch to Eclipse to do the check on return from
gdk_window_at_pointer, not sure how realistic that would be. I was
also thinking of ascending the tree until I hit a window that GDK is
aware of, but that would also require a patch to Eclipse.

I'm testing out calling gdk_foreign_new on all the children returned
by XQueryTree() when I'm creating the window for the first time,
although gdk_window_foreign_new seems to be hanging quite a bit when I
do that.

-Kevin.