GNOME Bugzilla – Bug 343104
GtkSocket doesn't send Configure events on move
Last modified: 2018-02-10 03:24:10 UTC
For an application using GtkPlug as its main window (such as Totem's Mozilla plugin), GtkPlug cannot be used effectively as it doesn't receive configure-events from the GtkSocket that embeds it. Adding the GDK_STRUCTURE_MASK to the events reported by the GtkPlug doesn't report any more GdkConfigureEvents.
This doesn't quite make sense to me: A) It must be receiving configure events, or all sorts of size stuff wouldn't work B) It's not normal to select for configure notify .. you normally look at size-allocate, which compresses multiple configures together It's possible that it's something mozilla-specific; I think you should do some experiments with testsocket in the GTK+ source tree.
After testing, I'll need to be a bit more precise. I get configure events: - when the widget is embedded (ie. straight after the GtkPlug created) - when resizing the GtkPlug I don't get any configure events when the GtkPlug is moved though (which is what I would need fixed to fix the Totem bug associated with this one).
Created attachment 66352 [details] [review] gtkplug-test-gtk-simple.patch This patch prints the configure events on the GtkPlug. It shows they are generated when the toplevel window is resized, but not when the toplevel window is moved.
Ah, yes, that's a known limitation and rather hard to fix ... imagine a GtkSocket inside a GtkViewport - the plug moves as the GtkViewport is scrolled; I think the best way to do it would probably to add some sort of facility to GDK for tracking the absolute origin of a GdkWindow ... maybe something like: gdk_window_set_track_origin(gboolean track_origin) and an ::origin-changed signal.
The GTK+ widgets other than my custom one in the Totem Mozilla plugin are getting moved properly though. Is there any other event I could track to know when my custom widget has been moved? I could then check on its position, which would be better than nothing.
The problem is not getting moved, the problem is knowing when you get moved; The embedder in the XEMBED protocol acts in many ways like a window manager, window managers are required by the ICCCM to send synthetic configure events when the frame window is moved because the app needs these to track its origin. GtkSocket doesn't send these events ... because it's really hard in GTK+ to keep track of when a widget's origin changes. The suggestion above is the simplest way I can think of fixing.
When/how should the ::origin-changed signal be sent? Should the window position be tracked via regular polling using gdk_window_get_geometry?
GTK+ already tracks the position of toplevel windows, by watching ConfigureNotify events. (Unless, of course, the toplevelwindow is inside a GtkSocket :-) The part that is missing is tracking the position of subwindows within a toplevel window. You'd need to keep a couple of bits on each window (whether the origin is tracked for the window, whether the origin is tracked for some subwindow), then send signals after gdk_window_move() and gdk_window_scroll().
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.