Re: GdkOffscreenHooks

[Alexander Larsson <alexl redhat com>]

On Tue, 2008-11-18 at 17:03 -0500, Owen Taylor wrote:

> It seems to me that it might be better to say that input redirection is
> restricted to the case where you have a "toplevel offscreen window" that
> is basically completely outside the normal widget tree.
> 
> Then you'd have functions like:
> 
>  void
>  gdk_offscreen_window_motion (GdkOffscreenWindow *window,
>                               GdkEventMotion     *motion,
>                               double              relative_x,
>                               double              relative_y);
> 
> (also enter/leave/button) that are used to to forward events to the
> toplevel offscreen window.

I'd like to note that we require something like this anyway for the case
where you embedd the offscreen windows in a non-gtk/gdk hierarchy. The
typical example would be a clutter scene.

Since we have to have this anyway and the number of users of this API is
likely to be small (only in canvas implementations and in clutter
integration) and since its a more powerful system I agree that it makes
sense to only support this.

Tim however expressed concerns that this means we'll get another
hierarchy split like with GtkPlug/GtkSocket. I.E. that if you try to get
the toplevel window from a widget inside the offscreen you'll get back
the widget that has the offscreen window rather than the actual toplevel
window. I don't personally think this is a large problem, as this only
happens for things embedded in canvases, which are rarely large complex
UIs that do a lot of complex stuff.

> - Ungrabbing implicit grabs (allowed by X/GDK) is a bit of a problem
>   since implicit grabs have to be maintained cooperatively between
>   the TOW and the container it is embedded in. You could add
>   a signal for that ungrab, or you could just ignore the problem;
>   I don't think the usage is common.
> 
> - Explicit pointer grabs also need consideration. Ideally we wouldn't 
>   have any explicit pointer grabs on subwindows but we still have
>   a few.

I think we could handle this by having a request_grab and request_ungrab
signal on the offscreen window and having the container monitor that for
all its offscreen children.