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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list