GNOME Bugzilla – Bug 731054
"minimum/natural size semantics" commit to GtkTreeView breaks GtkScrolledWindow
Last modified: 2017-10-07 13:44:03 UTC
Hi, Commit 6d53c2339f79baa0b295ecc614f41f9daab2e132 has broken GtkTreeView inside a GtkScrolledWindow, if fixed width columns are used. This is from GTK 3.7 onwards. commit 6d53c2339f79baa0b295ecc614f41f9daab2e132 Author: John Lindgren <john.lindgren@aol.com> Date: Tue Dec 18 02:06:12 2012 -0500 Use minimum/natural size semantics Rewrites gtk_tree_view_column_request_width() and gtk_tree_view_size_allocate_columns() to respect the minimum and natural sizes that are already being returned by gtk_cell_area_context_get_preferred_width(). Somehow it's not requesting the right width, so the horizontal scrollbar never displays. All the columns on the right which should be extending past the visible area just get squashed together on initial display of the TreeView. If you expand them, the scrollbars still don't display. I've attached a reproducer, which is basically the GTK tree_store.c demo without any real changes. Also a screenshot of it compiled against GTK 3.6.5, which displays the scrollbars fine, and running against 3.10.9 where you can see the scrollbars don't display. This is a pretty major issue for my application and I've spent a long time trying to find a workaround without success. If you could suggest a workaround I would really appreciate it. Thank you.
Created attachment 277631 [details] reproducer, the GTK tree_store.c demo
Created attachment 277633 [details] scrollbars working on GTK 3.6
Created attachment 277635 [details] scrollbar missing on GTK 3.10 (since 3.7)
(In reply to comment #0) > Hi, > > Commit 6d53c2339f79baa0b295ecc614f41f9daab2e132 has broken GtkTreeView inside a > GtkScrolledWindow, if fixed width columns are used. This is from GTK 3.7 > onwards. > > commit 6d53c2339f79baa0b295ecc614f41f9daab2e132 > Author: John Lindgren <john.lindgren@aol.com> > Date: Tue Dec 18 02:06:12 2012 -0500 > > Use minimum/natural size semantics > > Rewrites gtk_tree_view_column_request_width() and > gtk_tree_view_size_allocate_columns() to respect the minimum and natural > sizes that are already being returned by > gtk_cell_area_context_get_preferred_width(). > The above seems to be a misguided patch which assumes that reporting natural widths from treeview was not a dangerous activity. GtkTreeView does not have a full implementation of height for width, implementing it involves a major change in the way treeview requests sizes for rows in timeouts, it's not a change to be taken lightly. See bug 729341 for some additional comments on this.
I've reverted 6d53c2339f79baa0b295ecc614f41f9daab2e132 now.
https://bugzilla.gnome.org/show_bug.cgi?id=701899 was also caused by the reverted commit.
With this revert, expanded columns no longer get/give space when columns get resized. Is this intentional?
no
could you explain (maybe in a new bug) what you mean by get/give space ? I'm not sure I know what you mean.
Rhythmbox: * Make one column bigger. It gets set a fixed with and expand=false. * Before the revert, all other columns (expand=true) got smaller/bigger equally * Now the TV shifts out of the scrolled window.. only after resorting a column do the other column widths get corrected.
A new bug for that would be good, since it must be caused by something other than the commit that caused the original problem here.