GNOME Bugzilla – Bug 634592
GtkNotebook doesn't expand (in a typical GtkDialog)
Last modified: 2010-11-25 05:35:39 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.
Created attachment 174250 [details]
A screenshot of the dialog when using GTK+ 2. This looks OK.
Created attachment 174251 [details]
A screenshot of the dialog when using GTK+ 3. This looks wrong.
Note that my test case uses GtkBuilder.
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.
I think this probably fell apart when doing some GtkH/VBox -> GtkBox migration, since the fill default is different between those.
Javier, any idea ?
(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:
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.
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():
Created attachment 174592 [details] [review]
Actually, that does not seem to fix it. Here is the patch that I tried quickly.
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
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...
> 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.
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.
Author: Tristan Van Berkom <firstname.lastname@example.org>
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.