GTK3 size negotiation

[Tony Houghton <h realh co uk>]

I found a bug in the GTK3 version of my X terminal application, roxterm
<http://roxterm.sourceforge.net>: If you maximize a window with a single
tab then unmaximize it, its width increases to more than it was before
the window was maximized.

Unlike gnome-terminal, roxterm (optionally) always shows the tab bar.
When there are multiple tabs the children are set to expand and fill and
the tab bar spans the entire window. In this mode the window unmaximizes
to its correct size. With a single tab expand is FALSE and I've written
a custom label widget to try to make the tab approximately half the
width of the window, which looks good.

I realised why the size was changing: when the window is maximized, the
tab is wider than the window's unmaximized width. When unmaximizing GTK
prevents the window from becoing too small for that tab even though its
size is renegotiated so it's approximately half the window's new width.

During size negotiation the label has to request its mimimum_width to be
the target width. If I try to use natural_width instead it ignores it
and uses the minimum_width set by the base class, which is just enough
to show the three dots when it's fully ellipsized, so that's no good. [1]

I connected signal handlers for size-allocate and configure-event on the
toplevel window, but the first time they get called during unmaximizing
their data already contains the incorrect width based on the label's
maximized size, so it seems it's already decided on its new size before
any attempt to renegotiate the tab size can be performed. [2]

The solution I've settled on is to use a per-window variable to remember
the minimum negotiated size of a tab label and not exceed it. It feels
more like a kludge to work around misbehaviour in GTK3 than an elegant
solution.

[1] Why is natural_width being ignored? Has this not yet been
implemented properly in GTK3? Is it a bug?

[2] Surely this is a GTK3 bug?