Created attachment 190369 [details]
testcase.ui

Created attachment 190370 [details]
testcase.c

Build with:
gcc `pkg-config --cflags --libs gtk+-2.0` -Wall -O0 -g -o testcase testcase.c

Created attachment 190371 [details]
Screenshot of the testcase running with gtk+3 (buggy)

Created attachment 190372 [details]
Screenshot of the testcase running with gtk+2

I've reverted some of the gtkcellrenderertext.c get_layout() code and it's fixed it:

diff --git a/gtk/gtkcellrenderertext.c b/gtk/gtkcellrenderertext.c
index c5eed2e..6f807b7 100644
--- a/gtk/gtkcellrenderertext.c
+++ b/gtk/gtkcellrenderertext.c
@@ -1629,20 +1629,7 @@ get_layout (GtkCellRendererText *celltext,
 
   if (priv->wrap_width != -1)
     {
-      PangoRectangle rect;
-      gint           width, text_width;
-
-      pango_layout_get_extents (layout, NULL, &rect);
-      text_width = rect.width;
-
-      if (cell_area)
-       width = (cell_area->width - xpad * 2) * PANGO_SCALE;
-      else
-       width = priv->wrap_width * PANGO_SCALE;
-
-      width = MIN (width, text_width);
-
-      pango_layout_set_width (layout, width);
+      pango_layout_set_width (layout, priv->wrap_width * PANGO_SCALE);
       pango_layout_set_wrap (layout, priv->wrap_mode);
     }
   else


This is probably a hack, but probably points out a bug in the new size calculation there. That's from

commit e2a82c70b4cb8f59451f8b00dfce33a4f23ff998
Author: Tristan Van Berkom <tristan.van.berkom@gmail.com>
Date:   Wed Aug 18 19:36:51 2010 -0400

    Added/Implemented GtkCellSizeRequestIface
    
    This patch adds height-for-width geometry management
    for cell renderers while still responding to the old
    gtk_cell_renderer_get_size() apis with virtual return values
    (obtained by soliciting the new height-for-width cell renderer
    apis).

That is obviously a hack and fixes the height, but breaks e.g. automatically reflowing of text. A proper fix is needed.

(In reply to comment #0)
> If you set the width in a GtkCellRendererText, it will wrap the text at the
> wrong place, but it will request the right height (compared to what gtk+2 did),
> making it look ugly because there's a lot of empty vertical space.
> 
> E.g., for the same text and width, gtk+ 2 would do something like
> 
> /----------\
> |Happy     |
> |birthday  |
> |to you,   |
> |my friend |
> \----------/
> 
> But gtk+ 3 does
> 
> /------------------\
> |                  |
> |Happy birthday    |
> |to you, my friend |
> |                  |
> \------------------/

Yes, we are aware of this, height-for-width treeviews dont work yet,
however it is not a problem with cell renderers, GtkCellRenderer and
GtkCellArea *do* do height-for-width, but the treeview does not calculate
it all yet for all the variable height-for-width rows.

So, explanation of why it appears as it does above:

   in GTK2, you tell it the wrap width, it wraps to that width
   and then requires the height and width it needs

   in GTK3, if you tell the minimum wrap width that will be a good
   clue to not overwrap... however the height for the minimum width
   will be allocated to every row of the treeview.


To fix this problem what needs to be done (vaguely speaking, we've went
over it before Kris and I and some details might change):

   o GtkTreeView needs to keep track of which rows it requested

   o When GtkTreeView requests a batch of rows at a time

   o Request all the widths of the batch first

   o If the new width is larger then the last batch of row widths,
     then invalidate *all previously requested heights* (which 
     were requested for a different previous width).

   o Once we've requested a full batch that does not push the width
     of the view, start requesting height for width of each row

   o Whenever the width of the treeview is changed (by user resizing
     or whatever), then all the heights of every row must be invalidated
     and they should be requested at the new width.


That's more-or-less what treeview needs to do to offer real
height-for-width rows.

The bug still affects version 3.8.1

Still afftects 3.14 AFAIK and it makes windows using wrapping look ugly: https://gna.org/support/download.php?file_id=24328 - I would love if somebody could fix this, I lack the skills:-(.

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

Still an issue, new bug https://gitlab.gnome.org/GNOME/gtk/issues/12

Would you please include a link to the new bug so that it can be followed?

Oh, never mind, I put it in the comment above myself,sorry.