GNOME Bugzilla – Bug 770003
"How does the code know the size to allocate?" from gtk_window_check_resize() under gtk_container_idle_sizer()
Last modified: 2018-05-02 17:25:28 UTC
This is with gtk3-3.20.8-1.fc24. Running locally built test-html-editor from evolution-3.21.90/e-util (which is a noinst_PROGRAMS) shows a runtime warning: (test-html-editor:25481): Gtk-WARNING **: Allocating size to GtkWindow 0x108d450 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? With the below backtrace. Maybe there is something what the editor does wrong, but I do not know how to debug this further, thus any help will be appreciated. Note that the GtkWindow's parent is NULL. (gdb) bt
+ Trace 236547
Created attachment 348030 [details] test case This test case yields exactly the same stack trace.
The test case is a tree-view in a scrolled-window in the content-area of a dialog. The dialog is transient for a top-level window, which is there only because not having one "is discouraged". The "Allocating size" warning is not issued when the dialog is shown, but each time when the tree-view in the scrolled window is expanded.
Created attachment 348042 [details] simpler test case Turns out the dialog is not needed: adding the scrolled-window to a top-level window is enough to trigger the warnings each time the tree-view is expanded.
It looks like we ran into the same problem in our application.
This looks similar to bug 773814
Here's all I can figure out: • The warning is issued by gtk_widget_size_allocate_with_baseline() when gtk_widget_get_resize_needed() is TRUE; that's a macro that just returns widget->priv->resize_needed. • widget->priv->resize_needed is set only in gtk_widget_queue_resize_on_widget(), which is exported by gtkwidget.c but used only internally, by gtk_widget_queue_resize_internal(). • gtk_widget_queue_resize_internal() is called by gtk_widget_queue_resize_no_redraw() and by gtk_widget_queue_resize(). I ran the test case, and set breakpoints on both functions when the window was showing but before clicking the descender. In the dozen or so traps after clicking it and before the warning was issued, none was for the GtkWindow named in the warning. So it looks as though priv->resize_needed is not getting cleared after the initial drawing of the window.
AFAICT priv->resize_needed is cleared only by gtk_widget_ensure_resize(). Another debugging run shows that gtk_widget_ensure_resize() is *always* called at least once after gtk_widget_queue_resize() and before gtk_widget_size_allocate_with_baseline(). So it's unclear how it gets set to trigger the warning.
Created attachment 351836 [details] Gdb stack trace
The stack trace resulted from setting a breakpoint on gtk_widget_queue_resize_on_widget, which is called on the GtkWindow immediately before the call to gtk_widget_size_allocate_with_baseline that triggers the warning. Frame #24 is a call to gtk_widget_get_preferred_width, and ultimately at frame #1 gtk_widget_queue_resize_internal is called on an embedded widget, and then recurses up all the way to the toplevel window, setting resize_needed on all the widgets. The only obvious fix is a hack: call gtk_widget_ensure_resize on the window immediately after gtk_widget_get_preferred_width returns in gtk_window_get_preferred_width. The real solution would be to avoid setting resize_needed inside a call to gtk_widget_get_preferred_width, but that appears to need more intrusive changes.
(In reply to Peter Bloomfield from comment #9) > The only obvious fix is a hack: call gtk_widget_ensure_resize on the window > immediately after gtk_widget_get_preferred_width returns in > gtk_window_get_preferred_width. The real solution would be to avoid setting > resize_needed inside a call to gtk_widget_get_preferred_width, but that > appears to need more intrusive changes. Or the warning is simply useless, bothers users and developers, the most because it's a false-positive in valid cases. I saw it also with WebKitGTK+ (WebKit1) with embedded GtkWidget-s. The code knows the size, because the HTML code defining the embedded GtkWidget has appropriate values (width/hight) defined. That's something what gtk+ itself cannot cover by this runtime warning. Nonetheless, the above backtrace (this bug) is about gtk+ code only.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/658.