GdkOffscreenHooks

[Owen Taylor <otaylor redhat com>]

The input redirection in the offscreen branch is currently:

struct _GdkOffscreenChildHooks
{
  void       (*from_parent) (GdkWindow *offscreen_child,
                             gdouble    parent_x,
                             gdouble    parent_y,
                             gdouble   *child_x,
                             gdouble   *child_y);
  void       (*to_parent)   (GdkWindow *offscreen_child,
                             gdouble    child_x,
                             gdouble    child_y,
                             gdouble   *parent_x,
                             gdouble   *parent_y);
};

Which puts GTK+ in charge of everything, and the only interception
possible is choosing the actual transform. What if you wanted to have a
scene graph that combined redirected windows with other objects. And a
non-window object was obscuring the redirected window? It's not clear
how to handle that naturally.

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.

You'd have to be able to track the cursor, so you'd have a
signal ::displayed-cursor-changed and a function

 GdkCursor *
 gdk_offscreen_window_get_displayed_cursor(GdkOffscreenWindow);

Notes on the idea:

- The basic idea here is that the container where you are embedding
  the transformed window already has code for event propagation,
  child window picking, and implicit grabs (once you click on 
  an element, events keep going there until release), so we should
  just reuse that.

- You might sometimes want to do input redirection (like if you 
  were putting the window into a scene graph with other objects)
  but *not* do interesting transforms. In that case you want things   
  like popping up windows positioned with respect to other elements
  to work correctly. So, you probably do need to have a simple
  gboolean ::get_root_coordinates() callback/signal.

  If you do interesting transforms, then all bets are off.

- 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.

   gtk_paned_button_window(): If this one is needed at all it is
     to override some aspect of the implicit grab, so it could be
     done completely within the TOW code without server involvement.

   gtk_cell_renderer_accel_start_editing(): probably should be
     grabbing on a GtkInvisible instead. I think it's only here
     to avoid clicking off to some other program.

   gtkhsv.c:set_cross_grab(): Looks like it is used to override
     the cursor of the implicit grab - again could be done completely
     within the TOW.

  I'm not really worried if we need a few widget fixes to make things
  work with input redirection ... it's not like we are discussing
  doing input redirection within existing unmodified applications.

- Owen