GNOME Bugzilla – Bug 692322
InfoBar action-area's horizontal orientation tag is not saved
Last modified: 2018-03-26 15:27:08 UTC
Created attachment 234133 [details] sample gtkbuilder file The attached gtk builder file contains a GtkInfoBar called "warning_infobar". If you set its internal action_area's orientation to Vertical, it gets saved, however if you set it to horizontal, it does not get written to the resulting .ui file. The result is that applications that try to use this glade file through gobject introspection will never know about the orientation, so it will always show up with a vertical button arrangement. I don't know if this is the only widget affected, and the only property affected...
See also, potentially: bug #676488
Omitting the "orientation" property is exactly the same as specifying that the orientation property should be set to it's default value. Any omitted property is a property explicitly set to it's default value. In some corner cases, for instance the old GtkVBox class, we worked around bugs in GTK+ by explicitly setting the property in the Glade file no matter what the value. Those mentioned bugs were that, GtkVBox would set its orientation at gtk_vbox_init() time, but fail to change the default value of the orientation property advertised by it's orientation property in gtk_vbox_class_init(). In other words, in the few cases where widgets misbehave (i.e. don't behave according to the default values that they advertise), we make an exception and unconditionally save the property value.
Created attachment 234190 [details] test script Except that, as far as the attached script can reveal, the default value is Vertical, not Horizontal. The docs for GtkInfoBar confirm this: "In contrast to GtkDialog, which has a horizontal action area at the bottom, GtkInfoBar has a vertical action area at the side." If you do it programmatically or insert the missing horizontal orientation property line in a glade file, you can set the orientation to horizontal. However, Glade does not allow doing that through its UI, so you can never set the non-default value because the default value is actually Vertical.
Ah, this is a bit more complicated than the usual case (and sorry to be too quick on the trigger this morning). Notes on how this can be fixed: a.) Quick and dirty; manually save the infobar's internal child orientation property regardless of it's default value b.) Ideally: There is a routine when creating internal children where we double check and fetch the property values (this is how Glade get's the right non-default vertical value of the action area, instead of relying on the real default value set by it's GParamSpec) In that routine we should mark any properties that are non-default on newly created internal children of composite widgets. Properties on those internal children that are initially non-default should be saved regardless of the value.
Came back for another round of trying to figure out this bug. The option 'b' will not fix it because once we save it, we won't have history on the next load... of whether it should be saved or not regardless of the value. The option 'a' sucks because not only GtkInfoBar is effected, but every non-default value in an 'internal' widget (like GtkComboBox's entry, or GtkDialog's action area)... would need the same treatment... so it would have to set *all* properties of every internal widget. Another approach, is to use the "optional" property mechanism, which adds a check box beside the property (annoying extra click), such as is done with "width request" and "height request". But currently I only have optional settings described at the widget class level... so setting 'all of an internal widget's properties' to be optional would require some additional work (and would be annoying to work with too, because of all the little check boxes, but I think we could live with that). I'm currently a bit torn between: 1.) Adding the checkbox to every single property of an internal child. Which would be an ugly and annoying UI... or... 2.) Saving every property value of an internal child. Which would grow the GtkBuilder output... But I'm leaning towards 2... because there are not all that many internal widgets in a typical glade file, so perhaps it's not so bad.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glade/issues/115.