GNOME Bugzilla – Bug 769566
GtkScrollbar warning "How does the code know the size to allocate?"
Last modified: 2018-05-02 17:20:55 UTC
GTK3 on Arch was upgraded yesterday to 3.20.8, ever since then my application Terminix has been issuing the following warning to the console whenever I resize the window: (terminix:6853): Gtk-WARNING **: Allocating size to GtkScrollbar 0x15c65c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? I noticed that bug https://bugzilla.gnome.org/show_bug.cgi?id=765700 seems somewhat similar and I've tried commenting out the style and provider I add to the scrollbar to see if it made a difference but no change.
That is very hard to say, can you run your application in gdb with G_DEBUG=fatal-warnings and gtk+ debugging symbols and print a backtrace when that warning appears?
As requested: [Thread 0x7fffdb3fe700 (LWP 23358) exited] (terminix:23348): Gtk-WARNING **: Allocating size to GtkScrollbar 0x14d45c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? Thread 1 "terminix" received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff225570b in g_logv () from /usr/lib/libglib-2.0.so.0 (gdb) bt
+ Trace 236510
I started getting a similar message with xfce4-terminal after upgrading to gtk+ 3.20.8.
*** Bug 770228 has been marked as a duplicate of this bug. ***
*** Bug 770540 has been marked as a duplicate of this bug. ***
Not seeing this anymore after Arch Linux has upgraded to gtk+ 3.22.1.
Started seeing this again after upgrading to 3.22.8. Regression?
This might be related to bug 773814
I've made some investigation in bug 791014, and at this point I really need help from a GTK+ guru who can tell whether VTE is doing it wrong, or it's a GtkScrollbar bug. Copy-pasting here the most relevant bits: When the window height changes, GTK+ calls size_allocate for both VTE and the Scrollbar "in parallel". VTE handling this event also causes synchronous changes to the Adjustment (and in turn to the Scrollbar). That is, the Scrollbar receives changes both from the bottom (GTK+) and sideways (VTE) at the "same time". It looks to me that this is what Scrollbar doesn't like. We'd need input from a GTK+ expert whether this is really a sufficient reason for Scrollbar to warn and is really something we should avoid, or whether not being able to handle this is a bug in Scrollbar. A solution/workaround from VTE could be to defer these gtk_adjustment_set_whatever() calls to when idle. xfce4-terminal allows you to place the scrollbar on the left. The warning doesn't appear in that case. Debugging both VTE and GTK+ reveals that indeed size_allocate is called on the left widget first, then on the right. Apparently in the "scrollbar on the left" case it has already settled with the new allocation when VTE pokes it, so it's okay.
Created attachment 368165 [details] Minimal test case This tiny test app reproduces the warning exactly as in VTE-based apps. It consists of two widgets next to each other: a "fake vte" (a GtkLabel subclassed so that on size_allocate it modifies the adjustment), and a scrollbar reflecting the adjustment. Just as with the scrollbar on the left with xfce4-terminal, swapping the packing order makes the warning go away. I strongly suspect it's a GTK+ bug. I believe it should be a legal operation to alter the adjustment from a size_allocate, and that's what any VTE-like widget (with an external scrollbar, rather than being inside a GtkScrolledWindow) would also reasonably do. And, apart from this warning, it works correctly. (Note that there are plenty of other, non-VTE-related occurrences of this same warning posted across the web.)
*** Bug 791014 has been marked as a duplicate of this bug. ***
Benjamin (adding you to CC), You seem to be the guy who knows the story of this warning. Could you please look at this bug? I firmly suspect that in one particular case it's erroneously emitted by GTK+, as detailed in the previous comments. Thanks!
Ah yes, the adjustment issue. What happens in your example is this: 1. GtkBox::size-allocate is called. It queries sizes for its children and computes their allocations. 2. The box calls FakeVte::size-allocate. It updates the adjustment. 3. gtk_range_adjustment_value_changed() is triggered. It updates its presentation and while doing so calls gtk_widget_queue_resize(). 4. The box calls GtkScrollbar::size-allocate. The warning happens. Since the scrollbar queued a resize in #3 but the allocation was computed with the size request from #1, the warning is correct. I have no idea how a fix should look, but as long as the scrollbar/range code queues a resize during size allocation, that warning is correct.
I'm totally not familiar with GTK+ internals, so apologies in advance if my questions are silly. > 3. gtk_range_adjustment_value_changed() is triggered. It updates its > presentation and while doing so calls gtk_widget_queue_resize(). Why would a gtk_range_adjustment_{,value_}changed trigger a queue_resize()? I think it should only queue_draw. A change to the range parameters should only change how the GtkScrollbar renders its own contents (where it draws the handlebar), but nothing about its overall size/allocation. Or what am I missing? It's like as if VTE kept calling queue_resize on itself during its normal operation, like scrolling due to newly appeared output... no, this is its own private business, it repaints the contents without tampering with the allocation.
gtk_range_adjustment_{,value_}changed() call gtk_range_calc_slider() [and this latter method is solely called from these two]. gtk_range_calc_slider() calls gtk_css_gadget_queue_resize(priv->slider_gadget), and this is what in turn calls gtk_widget_queue_resize(range). I'm totally not familiar with the concept of gadgets, feels something like a "lightweight widget" to me. gtk_css_gadget_queue_resize() simply calls gtk_widget_queue_resize() on the gadget's owner widget. That looks like the problem here, because it's obviously needed to resize the slider gadget, but we'd need to avoid resizing the range widget. I'm on 3-22. 3.91.2's news says "All gadgets have been replaced by widgets", so I guess chances are the situation is completely different on gtk4 ??
Yes, GTK4 is completely different. Apparently, this resize was added because of bug 765410. Not that that bug explains much about why it's there.
Reverting that indeed eliminates this warning in this test app and VTE-based apps. When Matthias Clasen says "We haven't fully tracked down yet why a queue_allocation is not sufficient here, it should", Timm Bäder says "I don't know how to handle that case" and you say "I have no idea how a fix should look", I think it's time for me to give up :-D I probably won't be able to contribute anything more to this bug. I'm hoping it is (or will be) gone with gtk4. (I guess you wouldn't want to just entirely remove this warning from gtk3, right?) Until then, we'll just live with this warning, or I might work it around in VTE by changing the adjustment from idle.
What might work is trying to swap the order I outlined in comment 13. If you can make it so the adjustment gets set before the container tries measuring the children, you might get away without the warning.
(In reply to Benjamin Otte (Company) from comment #18) > If you can make it so the adjustment gets set before the container tries > measuring the children, you might get away without the warning. This would mean a subclassed GtkHBox or something similar, right? I'm not interested in any workaround that would go to gnome-terminal and leave the warning for all other VTE-based apps. I'd either like to see it being fixed or worked around in GTK+, for which I definitely don't have enough expertise and time, or in VTE. In the latter, the order in which the widgets' size-allocates are called is out of our control, in fact, I don't think there's even a way for VTE to find the scrollbar, or even to figure out whether it's shown at all. From VTE the only workaround I can think of is to delay changing the adjustment via e.g. g_idle_add().
Created attachment 368224 [details] [review] VTE workaround VTE already sets upper/lower asynchronously, so just simply move the setting of pagesize/pageincr/stepincr there as well.
See also bug 767136, and Timm's suggestion there to guard this warning with G_ENABLE_CONSISTENCY_CHECKS.
*** Bug 793679 has been marked as a duplicate of this bug. ***
Comment on attachment 368224 [details] [review] VTE workaround (VTE workaround was reviewed in bug 793435; submitted for 0.52.)
How to stop this madness all SYSTEM JOURNAL in that JOKE WARNING! It's like a spam. Is there some compiler flags to fix it?
> It's like a spam. So is your comment. > Is there some compiler flags to fix it? No. If you compile gtk3 yourself anyway, you can as well just remove that one line for the warning, if you really care so much.
This bug is like in all gtk apps with custom widgets and comportability of gtk versions less than 3.20. Is it OK? Can you make this warn shorter? This funny question at least... BTW I fixed my apps but I can't fix all of them.
See https://bugzilla.gnome.org/show_bug.cgi?id=767136#c6 onwards, culminating in today's https://gitlab.gnome.org/GNOME/gtk/commit/eb01ba8573bec47e02c8fc4eaf10e2f7cff522dd
Awesome! :)
-- 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/650.