After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731054 - "minimum/natural size semantics" commit to GtkTreeView breaks GtkScrolledWindow
"minimum/natural size semantics" commit to GtkTreeView breaks GtkScrolledWindow
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-05-31 18:46 UTC by ajf
Modified: 2017-10-07 13:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
reproducer, the GTK tree_store.c demo (13.06 KB, text/plain)
2014-05-31 18:46 UTC, ajf
Details
scrollbars working on GTK 3.6 (27.78 KB, image/png)
2014-05-31 18:47 UTC, ajf
Details
scrollbar missing on GTK 3.10 (since 3.7) (32.51 KB, image/png)
2014-05-31 18:47 UTC, ajf
Details

Description ajf 2014-05-31 18:46:06 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.
Comment 1 ajf 2014-05-31 18:46:41 UTC
Created attachment 277631 [details]
reproducer, the GTK tree_store.c demo
Comment 2 ajf 2014-05-31 18:47:05 UTC
Created attachment 277633 [details]
scrollbars working on GTK 3.6
Comment 3 ajf 2014-05-31 18:47:40 UTC
Created attachment 277635 [details]
scrollbar missing on GTK 3.10 (since 3.7)
Comment 4 Tristan Van Berkom 2014-05-31 19:35:04 UTC
(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.
Comment 5 Matthias Clasen 2014-06-01 14:31:34 UTC
I've reverted 6d53c2339f79baa0b295ecc614f41f9daab2e132 now.
Comment 6 Christoph Reiter (lazka) 2014-06-01 18:18:24 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=701899 was also caused by the reverted commit.
Comment 7 Christoph Reiter (lazka) 2014-06-01 22:05:38 UTC
With this revert, expanded columns no longer get/give space when columns get resized.

Is this intentional?
Comment 8 Matthias Clasen 2014-06-01 22:45:01 UTC
no
Comment 9 Matthias Clasen 2014-06-01 23:11:36 UTC
could you explain (maybe in a new bug) what you mean by get/give space ? I'm not sure I know what you mean.
Comment 10 Christoph Reiter (lazka) 2014-06-01 23:21:39 UTC
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.
Comment 11 Daniel Boles 2017-10-07 13:44:03 UTC
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.