Re: GTK3 size negotiation

[Tony Houghton <h realh co uk>]

On Tue, 27 Sep 2011 12:06:06 -0400
Tristan Van Berkom <tvb gnome org> wrote:

> On Tue, Sep 27, 2011 at 10:04 AM, Tony Houghton <h realh co uk> wrote:
> > 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.
> 
> Hi,
>    Just a friendly reminder, in general this kind of query should probably go
> to gtk-app-devel-list (a list about developing with GTK+), we like to keep
> this list limited to discussion on the development of GTK+ itself.

OK. But I thought it was on topic because there does seem to be a
problem with GTK, but I don't know exactly what the bug is and what
component(s) it's in so I wanted to discuss it before filing a bugrep.

BTW, I posted about g-ir-scanner on the list because I was pointed to it
by <https://live.gnome.org/GObjectIntrospection>. I thought it was a bit
strange though. Would gtk-app-devel-list be more appropriate for that
too? I'm surprised not to find lists especially for
glib/gobject/introspection.

> Comments below...
> 
> > 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]
> 
> That's a problem with the parent container, if it's modern and uses
> gtk_distribute_natural_allocation() for size allocations then you wont
> have this problem. (if your "tab bar" is a GtkBox or GtkGrid derived widget
> then it should allocate correctly, if it's a custom widget, it should be
> ported to use modern allocation logic).
> 
> If we are taking about the tabs built-in to a GtkNotebook, then perhaps
> it's worthwhile to write a very short test case showing the bad behavour
> (I'm thinking a test case with just a window with a notebook and a "broken"
> ellipsized tab would be perfect) and file a bug against the notebook widget
> with that here:
>     http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B

It is a GtkNotebook. I haven't checked yet whether it's specific to that
or containers in general.

> > 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
> > maxtimized size, so it seems it's already decided on its new size before
> > any attempt to renegotiate the tab size can be performed. [2]
> 
> That's normal, size requests are cached, widgets are only re-requested
> if their content changes (or say, the height might be re-requested in
> response to a window resize if the widget is height-for-width).

On reflection, it's actually quite reasonable for GTK not to make the
window smaller than the maximized size of the tab, seeing as I requested
that size as a minimum. So the real problem is that the "natural" size
is being ignored. Again, when writing a container, it might seem
reasonable to use the minimum size when the expand flag is false, but it
overlooks the issue of causing unwanted ellipsizing. And if the text
size is small for other reasons (eg a roxterm tab label contains only
'~') it can make visible/interactive containers like notebook tabs
too small for convenience or aesthetics.