GNOME Bugzilla – Bug 675290
Broken sizing when inside a scrolled window
Last modified: 2018-05-02 15:24:47 UTC
Created attachment 213265 [details] testiconview.c GTK+ git master With the attached test application, the size of the window should be the same in both cases, as the natural and minimum size of the window should be the same. Toggle the #if 0 to see both cases. See also bug 673326 and bug 672173.
Created attachment 213268 [details] too small
Created attachment 213269 [details] correct size
Created attachment 213370 [details] expanded testcase Here is an expansion of the testcase. It can now be controlled by env vars: SCROLLEDWINDOW=1 - use a scrolled window ICONVIEW=1 - use an icon view as child, else use a label MINHEIGHT=1 - set min-content-height on the scrolled window
Created attachment 213372 [details] current result Here is how the current code sizes SCROLLEDWINDOW=1 ./testiconview
Created attachment 213373 [details] [review] a scrolledwindow patch I feel that this is wrong - the scrolledwindow should still request enough size to show its child. Here is a patch that does that.
Created attachment 213374 [details] with the patch With the patch, things are much better, but it turns out the viewport gets its allocation messed up with padding and border...
Created attachment 213375 [details] [review] forcing padding and border to 0 With this test patch to force padding and borders to zero, things work as expected.
Created attachment 213376 [details] look ma, no scrollbar
Created attachment 213377 [details] the scrolled window can still be resized smaller
Created attachment 213378 [details] and setting a min-content-height still forces the initial height
Of course, these patches don't fix the icon view size request code, which is still broken and doesn't layout before requesting a height.
(Summarized paste from an IRC discussion) So the thing is: (1) How size requests interact with scrollable widgets is completely undefined The icon view currently requests a random size and then the scrolled window assigns something roughly unrelated to it. I'm not sure there is completely no interaction, there might be. But even the values in those scrollbars are in no way related to the size requests. (2) Iconview knows exactly the sizes it should have inside a scrolled window The iconview can request a proper minimum and natural width and height and width for height and height for width. It computes the column width and height it's going to use in advance and from that, it can pretty much compute everything. So minimum width is 1 column, natural width is X columns (figure out a sane number here or just use N_ICONS). And for height ROWS, it's 1 and MIN (X, N_ICONS / ROWS). And the same math goes for height and height for width. This should be roughly trivial. The problem is that there's no way to communicate this to the scrolled window. But the solution we want to have in the end is to keep the max_cell_width/height current at all times (or rather: for size requests and allocations) and then go from there.
And to summarize some more: I dispute (1) - it may not work perfectly in practice, but it is far from 'completely undefined'. The way to communicate your sizing needs is by implementing get_preferred_width/height, etc...
The main problem in trying to force a size on the scrolled window is that it's impossible to get useful data out of the GtkIconView for sizing. For example, I know the width of the window (therefore the GtkIconView), and I want to compute the height myself to check whether it's above a threshold, and size up the window myself. I cannot, because GtkIconView thinks it's fine to have a natural size where neither its icon nor the associated label can fit. That's ludicrous.
Created attachment 213382 [details] [review] iconview: prove a point Feel free to apply this patch and test how much it effects icon views inside scrolled windows. All I managed to do with this is make applications behave weird that don't use scrolled windows.
With the recent changes to GtkIconView in master, gtk_widget_get_preferred_height_for_width() seems to work, which means we can size our windows correctly.
What's still outstanding here?
-- 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/394.