After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 634592 - GtkNotebook doesn't expand (in a typical GtkDialog)
GtkNotebook doesn't expand (in a typical GtkDialog)
Product: gtk+
Classification: Platform
Component: Widget: Other
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2010-11-11 14:37 UTC by Murray Cumming
Modified: 2010-11-25 05:35 UTC
See Also:
GNOME target: ---
GNOME version: ---

notebook_not_expanding.tar.gz (1.66 KB, application/x-compressed-tar)
2010-11-11 14:37 UTC, Murray Cumming
screenshot_gtk2.png (10.99 KB, image/png)
2010-11-11 14:39 UTC, Murray Cumming
screenshot_gtk3.png (11.06 KB, image/png)
2010-11-11 14:40 UTC, Murray Cumming
  Details (6.94 KB, application/x-glade)
2010-11-11 15:03 UTC, Murray Cumming
gtkbox_fill_fix_attempt.patch (1.01 KB, patch)
2010-11-16 09:40 UTC, Murray Cumming
none Details | Review

Description Murray Cumming 2010-11-11 14:37:21 UTC
Created attachment 174249 [details]

Here is a fairly simple test case that shows a problem I'm seeing in Glom when using GTK+ 3. The notebook in this GtkDialog doesn't expand to fill the extra vertical space.
Comment 1 Murray Cumming 2010-11-11 14:39:55 UTC
Created attachment 174250 [details]

A screenshot of the dialog when using GTK+ 2. This looks OK.
Comment 2 Murray Cumming 2010-11-11 14:40:26 UTC
Created attachment 174251 [details]

A screenshot of the dialog when using GTK+ 3. This looks wrong.
Comment 3 Murray Cumming 2010-11-11 14:40:57 UTC
Note that my test case uses GtkBuilder.
Comment 4 Murray Cumming 2010-11-11 15:03:05 UTC
Created attachment 174255 [details]

As suggested by Matthias Claasen, adding a fill=true to the packing section of the hbox fixes this.

But it shouldn't be necessary to add that (and Glade doesn't, probably assuming that it's the default) to avoid a regression when porting to GTK+ 3.
Comment 5 Matthias Clasen 2010-11-11 15:15:43 UTC
I think this probably fell apart when doing some GtkH/VBox -> GtkBox migration, since the fill default is different between those.

Javier, any idea ?
Comment 6 Murray Cumming 2010-11-12 12:39:02 UTC
(In reply to comment #5)
> I think this probably fell apart when doing some GtkH/VBox -> GtkBox migration,
> since the fill default is different between those.

Yes, the "fill" child property defaults to TRUE in GTK+ 2.24:
But it defaults to FALSE in GTK+ 3:

What's the reason for that? You (Matthias) changed this during this commit, though I don't see a clear explanation:
Comment 7 Murray Cumming 2010-11-12 12:41:29 UTC
I see the comment in those docs saying that the default is still the same in the GtkHBox and GtkVBox, probably done by this code
but I guess that's not working.
Comment 8 Murray Cumming 2010-11-12 12:43:14 UTC
Well, (sorry for the many quick comments), I guess the problem is that it just doesn't set the old fill default here in _gtk_box_set_old_defaults():
Comment 9 Murray Cumming 2010-11-16 09:40:09 UTC
Created attachment 174592 [details] [review]

Actually, that does not seem to fix it. Here is the patch that I tried quickly.
Comment 10 Tristan Van Berkom 2010-11-16 14:17:10 UTC
A quick look at gtk_dialog_init() shows that GtkDialog does not
use a GtkVBox but uses a vertically oriented GtkBox.

I'm really not sure what the call should be here. If the defaults
have been changed for 3.0; we probably don't want to go ahead and 
set the old defaults on composite widget's internal boxes since 
that seems to obsolete the default property value changes (it shows
indecisiveness on our part, I would rather we change the defaults
GTK+ wide or not change them at all)... however we are left with
these glitches.

My initial feeling is that Glade should make the conversion
when loading projects that target GTK+ < 3.0, but since Glade
for GTK+ 3.0 is not here yet (I would like to make it available
by the 3.0 release but I really cant be sure at this time)..
maybe it will be best to offer a conversion script for builder
files in the mean time.

On the other hand... it's also probably possible for GTK+ to
handle this internally/smoothly... for instance... a GtkBox,
when deserializing properties should be able to check
if the GtkBuilder xml target GTK+ version < 3.0... load
the properties assuming the old default values... otherwise
load the properties assuming the new default values.

Anyway, some food for thought if not a direct fix...
Comment 11 Murray Cumming 2010-11-16 16:32:30 UTC
> A quick look at gtk_dialog_init() shows that GtkDialog does not
> use a GtkVBox but uses a vertically oriented GtkBox.

Ah, yes. I am surprised that there's no bug when GtkBuilder finds a GtkBox instead of a GtkVBox. Maybe it just doesn't try to do anything GtkVBox-specific.
But maybe it could change the default if it _expects_ to find a GtkVBox (if the .glade file has a GtkVBox instead of a GtkBox).

And my patch is useless because it already (re)used the TRUE default for expand, for fill, though I would prefer that to be commented.
Comment 12 Tristan Van Berkom 2010-11-25 05:35:39 UTC
Fixed in master, actually we should go ahead and deprecate (or even
remove if it's not too late) the expand/fill properties of GtkBox.

commit eb5a5004959227d22b2f98a157beda8600df00d3
Author: Tristan Van Berkom <>
Date:   Thu Nov 25 14:37:02 2010 +0900

    Changing GtkBox:fill child property default back to TRUE.
    Since Havoc's patches introducing the GtkWidget halign/valign
    properties, fill should always be TRUE. If the widget should
    not fill its allocated space then it should set the halign or
    valign properties for that purpose.
    This also consequently fixes bug 634592.