Created attachment 137533 [details]
How the git commit dialog should look (with the bad commit reverted)

Created attachment 137534 [details]
Commit dialog with faulty orientation (with the bad commit)

Created attachment 137535 [details]
GtkBuilder file that shows this behavior

To clarify, the Glade file in question has not changed
from one version to the next, only the way its viewed inside Glade ?

Could you say if saving the Glade file with the new version
changes the Glade file content ?

Seems this may be a symptom of GTK+ not declaring the correct
default value of the orientation property correctly in subclasses.

We rely on the fact that an unmentioned property is equivalent
to a property explicitly set to its default value.

Ok, the commit you noted unmasked a problem that was silently there.

The vboxes appeared vertical but as far as Glade data is concerned,
they were horizontal.

Fixing this in Glade cannot be done afaics without ensuring that
it would break once its properly fixed in GTK+.

Reassigning to GTK+, the bug is that the orientation property
of GtkVBox should have a default value of "vertical".

Updating bug title.

See bug 540829

(In reply to comment #4)
> To clarify, the Glade file in question has not changed
> from one version to the next, only the way its viewed inside Glade ?
I just did some quick testing, and this only seems to affect display inside glade. The dialogs have the right orientation when running in Anjuta. 

To clarify a somewhat foggy issue.

If the dialogs show up in the right orientation in Anjuta, 
this denotes a bug in GTK+:
   "Unspecified properties dont load at their default value when objects
    are instantiated by GtkBuilder or otherwise"

The fact that this bug didnt show up sooner is because of a regression
in Glade, I altered the load process for optimization purposes, to load
the properties in the order listed in the Glade file instead of in
the order they are listed on the class - in this patch I missed the
synchronization of the remaining properties.

So what we ended up with is, a GTK+ core that loads vboxes vertically
accidentally (because of unspecified property) and a Glade that loads
the vboxes with no orientation specified - displays them horizontally
by accident - but correctly displays the property set at its default
value: _horizontal_ .

Extraneously complex code could be added to Glade to check if the
property was specified at load time, and then introspect the runtime
value of the property as opposed to the default value (as an exception
we do that at object creation time), and then set it to "save-always"
(which is usually the catch all hack we use to step around these problems,
unfortunatly just setting this one save-always doesnt solve our problems).
... adding that kindof logic to Glade quickly translates to redefining 
Glade's behavior, more bugs, ultimately just a mess when what we should
really do is just fix the bug.

No, it is not accidentally that vboxes come out vertically, it is intentional...
If you look at gtk_vbox_init(), you will notice that we set the orientation property to the correct value. It is explicitly done in this way so that we catch _all_ instantiations of vboxes, regardless of gtk_vbox_new() or g_object_new(). 

The only error you could argue for here is that we fail to redeclare the orientation property with the correct default value for vboxes. But we do make sure that vboxes have the correct initial value at runtime.

Perhaps I didnt phrase that correctly.

When creating an object, with g_object_new(), or with
gtk_builder_add_from_file(), you expect properties that
go unmentioned to have the default value advertized by
the pspec (the principal of leaving unmentioned properties 
in Glade files depends on this).

Maybe accidental is not the right word to use, but the
point is an unmentioned property is like an explicit 
default property, so if you see a vertical vbox at runtime,
assuming there was no mentioned orientation; that is
unexpected behavior, because the file explicitly listed
the vbox as horizontal.

As I tried to convey, the correct default value for the orientation of a vbox is 'vertical' (kinda obvious...). Whats amiss here is that we don't do a very good job of ensuring that the default value reported by the pspec matches the actual initial value. In some cases that is simply impossible, such as object-valued properties. In this case, it is simply because gobject makes changing default values in derived classes too hard to bother...

Ofcourse, the root of the bug is that the default value is not
reported correctly, Im not trying to argue that. I was just trying
to clarify (initially for James' sake) why a Glade file when
loaded with a vbox:orientation set to horizontal loads vertically
in GTK+.

As I said, normally we have workarounds, by always saving the
property; but usually its the case of a subclass that has
the property wrong (not a new property introduced with the
wrong default and so widely apparent).

In a normal case when using Glade if we missed the bug early 
and had to mark save-always later (we mark them as they are
reported/discovered), you may have had to manually edit 
the project with the bugfixed Glade version for the project 
the load correctly in libglade/GtkBuilder.

The idea ofcourse has occurred to us before to maintain
a corrected default value in our catalogs, but thats
an effort IMO better spent actually fixing the default
values in GTK+, not to mention it causes a whole nightmare
of versioning skews if ever GTK+ decides to change the default
value of a property in a new release.

*** Bug 589192 has been marked as a duplicate of this bug. ***

I see. As an end-user of glade, this bug results in a *very* poor experience indeed. It means going through all glade files I've made, and updating them to be 'correct', when it wasn't me that saved them incorrectly to start with. If I uncovered such as issue with my employer, asking end-users to jump through hoops to correct the issue simply would not be an option - we'd do a code fix *with* a data fix, as complex as that might be. I understand that resources might be limited, but each time my tools burn me to this extend ( and trust me, a quick look at other glade files tells me that I'm quite burned indeed ), I *seriously* consider alternatives. And I'm the local open-source enthusiast here.

The Glade files dont need to be updated, the missing
property should mean "default", currently that means
horizontal, fixing the default in GTK+ will fix this
with no manual fixing of your Glade file.

If this is uncomfortable to you then I really hope you 
fix it.

> If this is uncomfortable to you then I really
> hope you fix it.

That's not something that I'm really capable of doing at this point. I'm a Perl developer ( Gtk2-Perl in this instance ). I've had a go at hacking some C stuff. My first attempt was to fix a long-standing data-loss bug with GtkComboBoxEntry widgets. My patch remains, unconfirmed, and rotting: Bug 156017

So yes, I try to fix things as I come across them. But my lack of C skills, and also the lack of any attention to my above patch seriously dampens my ability and propensity to hack further.

*** Bug 589646 has been marked as a duplicate of this bug. ***

This also affects GtkVSeparator's.

Created attachment 141799 [details]
workaround python script which fixes/adds orientations for vboxes and vseparators

Here's a python script I ginned up with my mediocre python skills that goes through the XML glade file and finds GtkVBox and GtkVSeparator widgets which either don't have the orientation property or have a horizontal one and adds/fixes them.  It outputs the resulting file with a ".fixed" extension added.

If there are other classes that need the same fix, it should be easy for someone to add them and obsolete this version.

You'll probably want to open the resulting file in glade and save it again to get the formatting the way glade normally has it.

Make sure you make the file executable to be able to run it, or run it through your python interpreter manually.

Usage: ./fixup.py foo.glade bar.glade ...

DISCLAIMER:
Your mileage may very.  Use at your own risk.  No warranty.  This script may not work at all for you, it might kill your children, empty your bank account, red ring your xbox, etc.  I take no responsibility.  Consider me a homeless guy you've never met before offering you a drink of a strange yellow liquid from a old moldy bottle....  I smell funny too.

While we dont have a proper api in GObject to do this nicely,

I think its merited in this special case to do it rudely in
GtkOrientable implementations using g_object_class_install_property()
directly (while its not a nice way, at least it is the current
way to do this).

its an easy patch... I should write it soon...

Note: I have ofcourse been thinking of ways around this in Glade,
the one that came to mind was we could mark the orientation property
as "save-always", and include a clause at load time to load the runtime
value of a loaded object instead of the default value for "save-always"
properties (the logic would be a missing "save-always" property is
erronous and needs fixing).

But this wont work well, we need to be able to completely omit
the orientation property from the Glade file and orient properly
because we need also to support targetting of GTK+ <= 2.16; cases
where the "orientation" property doesn't yet exist (ofcourse adding
more and more clauses around here is possible, but its a slippery
slope...).

*** Bug 607218 has been marked as a duplicate of this bug. ***

I tried to create a patch for gtk+ the way Tristan proposed but this would become really ugly. It's not just that we have to add g_object_class_install_property() everywhere, we would also have to overloads for the property_set() and property_get() methods. This would definitly become really ugly. I could write such a patch though, if gtk+ maintainers really want to see it.

Here is a list of classes that I think are affected:

GtkVBox
GtkVButtonBox
GtkVScrollbar
GtkVRuler
GtkVSeperator
GtkVPaned

I would really appreciate if this could be fixed before 2.30 as it really disturbing when trying to edit gtkbuilder files.

*** Bug 584029 has been marked as a duplicate of this bug. ***

closing, as all the h/v classes have been deprecated