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 650267 - GtkTextView not handling height-for-width properly
GtkTextView not handling height-for-width properly
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2011-05-15 23:25 UTC by Andrew Cowie
Modified: 2018-02-10 03:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case (1.39 KB, text/plain)
2012-04-20 22:25 UTC, Paul
Details

Description Andrew Cowie 2011-05-15 23:25:18 UTC
When placed in a GtkGrid a GtkTextView with wrapping text is initially allocated the wrong size - it gets what appears to be its minimum size (natural size was same) size which turns out to be narrow and very tall.

Presumably the right thing to do is to call gtk_widget_set_hexpand() TRUE, but if you do so the GtkTextView is mis-allocated a huge vertical space (possibly corresponding to the minimum or natural vertical size request as above) although it then extends horizontally out to margin and wraps properly. 

The real problem is that shorly thereafter (ie, when you click in the GtkTextView or focus in (!)) it suddenly and jarringly re-allocates to the parent container's actual supplied size and re-wraps. Bang!

[The GtkTextView is not a direct child of a GtkScrolledWindow, it's just added to some other normal GtkContainer. Even though its not it a ScrolledWindow it should still work, right? Also, this first cropped up with GtkVBoxes, so its not a GtkGrid problem per se]

AfC
Comment 1 Andrew Cowie 2011-05-18 04:00:53 UTC
I put up a screenshot of what it looks like when it initially allocates & draws,

http://people.gnome.org/~afcowie/bug-650267-GtkTextView-IncorrectAllocation_Screenshot.png

and this is what it [correctly] looks like after you click somewhere inside the GtkScrolledWindow » GtkGrid » GtkTextViews,

http://research.operationaldynamics.com/projects/quill/files/Editor_Screenshot.png

I've converted the entire application from using nested GtkVBox and GtkHBoxes to using GtkGrid per Benjamin's suggestion [which long term needed doing anyway] but unfortunately it didn't help.

Debugging by hooking up to the 'size-allocate' signal to a representative GtkTextView shows things like this:

          alloc      pref(min)      pref(nat)
        514x190         508x82         508x82
        514x208         496x82         496x82
         514x82         508x82         508x82
         514x82         496x82         496x82

I can post numbers without gtk_widget_set_hexpand() TRUE but that would be "wrong", right?

AfC
Comment 2 Paul 2012-04-20 22:25:19 UTC
Created attachment 212465 [details]
Test case

I'm also seeing this issue and am attaching a simple test case here.

Although the window gets its requested 500 px width the GtkTextViews only get 82 px giving the "narrow and very tall" appearance commented on earlier. Moreover, each GtkTextView (except the one left with the focus) receives extra vertical padding which suddenly disappears when clicked on (a manifestation of commit 015f227 which queues a resize instead of just doing a redraw after a state change).

Setting hexpand TRUE does cause the GtktextViews to assume a natural size initially, but I then see the same problems as before after widening the window enough that the text renders in fewer lines: the GtkTextViews without the focus keep their vertical size, thus introducing new vertical padding. This seemed to start happening around commit 887142f. Like before, these affected GtkTextViews will instantly shrink, jarringly, when clicked on.

Any thoughts, suggestions, workarounds or fixes would be appreciated.
Comment 3 Matthias Clasen 2018-02-10 03:21:30 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.