Re: GTK3 size negotiation

[Tristan Van Berkom <tvb gnome org>]

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.

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

> 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).

Cheers,
      -Tristan