Re: GTK3 size negotiation

[Tristan Van Berkom <tristanvb openismus com>]

On Wed, 2011-09-28 at 15:25 +0100, Tony Houghton wrote:
> 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.

GObject/GLib/[GIO Also ?] are all discussed on the GTK+ lists
(historically they are all the same project, GObject was
originally GtkObject and glib/gobject then grew out GIO etc).

For gobject-introspection you might have a harder time
finding people who are "in the know", trying gtk-app-devel-list
is a very good start, also opening up an irc client and asking
a question in #gobject-introspection... and then leaving your
irc client run for a good few hours on a weekday afternoon,
is also a very good bet.

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

Then I would try the new GTK+ to check if your bug is fixed.

I suspect it is, the release notes a few days ago highlight new h4w 
support in GtkNotebook:
http://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00175.html

Cheers,
         -Tristan

> > > 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.
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list