- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Subject: GdkOffscreenHooks
- Date: Tue, 18 Nov 2008 17:03:12 -0500
The input redirection in the offscreen branch is currently:
void (*from_parent) (GdkWindow *offscreen_child,
void (*to_parent) (GdkWindow *offscreen_child,
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:
gdk_offscreen_window_motion (GdkOffscreenWindow *window,
(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
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
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.
] [Thread Prev