GNOME Bugzilla – Bug 767136
opening pdf results in a gtk-warning (How does the code know the size to allocate)
Last modified: 2018-05-02 17:12:19 UTC
xdg-open file.pdf results in the following warning in the terminal: (evince:3240): Gtk-WARNING **: Allocating size to EvSidebar 0x564f7b84c330 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Just saw this error on my Arch x64 with Gnome 3.20. This also happens with `gvfs-open`. I also want to add that this also happens when the document is opened from Nautilus or other UI programs. The resulting bad behaviour is that Evince is drawn incorrectly sometimes and buttons become unclickable until the window is manually resized.
I've tried to track down the source of this warning message and I think it's a bug in GTK. It's something to do with the way evince hides the sidebar until a document is loaded. The sidebar is implemented as a GtkPaned which contains a GtkScrolledWindow. Hiding and showing the scrolled window this way causes the warning message.
Created attachment 345532 [details] ev-test.c (test program) The attached program basically reproduces what evince does. It creates a window with a GtkPaned containing a GtkScrolledWindow and the scrolled window initially hidden. A document loading in the background is simulated by g_idle_add. The scrolled window is shown after "document loading" completes in the g_idle callback, and then the warning message is displayed. This compiles with "gcc -o ev-test ev-test.c $(pkg-config --libs --cflags gtk+-3.0)". I've tested with gtk 3.22.7 on Debian and with the git master; both produce the warning.
GtkPaned calls gtk_paned_calc_position in its ::size-allocate implementation (gtk_paned_allocate), which eventually calls gtk_widget_set_child_visible on the now-visible first child, aka. priv->child1. In GtkScrolledWindow's ::realize implementation, it calls gtk_scrolled_window_sync_use_indicators, which then creates the indicators and adds them to the scrolledwindow, via gtk_widget_set_parent. That calls gtk_widget_queue_resize on the parent widget if both parent and child are visible. I.e. this is the old "queue_resize during size-allocate" problem. For which we don't have a real solution. The g_warning call should probably be in a #ifdef G_ENABLE_CONSISTENCY_CHECKS instead of just G_ENABLE_DEBUG. Full backtrace of the offending queue_resize call:
+ Trace 237134
(Rest of the bt omitted)
(In reply to Timm Bäder from comment #4) > I.e. this is the old "queue_resize during size-allocate" problem. For which > we don't have a real solution. The g_warning call should probably be in a > #ifdef G_ENABLE_CONSISTENCY_CHECKS instead of just G_ENABLE_DEBUG. Are most reports of this warning from benign use cases, rather than people getting things wrong? If so, it would be nice not to have it yelling at me every time my program starts. :) Though I can't remember what the sequence was, need to do another bt, but IIRC I could not see anything actually wrong or any way around it in my case.
(In reply to Daniel Boles from comment #5) > (In reply to Timm Bäder from comment #4) > > I.e. this is the old "queue_resize during size-allocate" problem. For which > > we don't have a real solution. The g_warning call should probably be in a > > #ifdef G_ENABLE_CONSISTENCY_CHECKS instead of just G_ENABLE_DEBUG. > > Are most reports of this warning from benign use cases, rather than people > getting things wrong? I don't have any statistical data on that of course, but I know a few cases where the warning is justified and causes actual problems. > If so, it would be nice not to have it yelling at me every time my program > starts. :) Though I can't remember what the sequence was, need to do another > bt, but IIRC I could not see anything actually wrong or any way around it in > my case. Yes, it's done in quite a few widgets in gtk+.
I do everything from the command line. There are about 30 terminals going. I wish this could be cleaned up and no warnings emitted: $ evince flutterby.pdf (evince:446): Gtk-WARNING **: Allocating size to EvSidebar 0x56278c8724f0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? $
(In reply to Timm Bäder from comment #4) > The g_warning call should probably be in a > #ifdef G_ENABLE_CONSISTENCY_CHECKS instead of just G_ENABLE_DEBUG. Yes, please! :) See also bug 769566 comment 9 onwards for one particular case that erroneously leads to this warning. I don't know if Evince is also doing the same, or it's a different story.
I've pushed https://gitlab.gnome.org/GNOME/gtk/commit/eb01ba8573bec47e02c8fc4eaf10e2f7cff522dd in the meantime.
-- 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/632.