GNOME Bugzilla – Bug 539907
Improve GtkHButtonBox allocation < requisition behaviour
Last modified: 2013-02-13 04:24:36 UTC
The GtkHButtonBox, as used to implement the action area in GtkDialog, packs buttons homogenously, meaning that every button has the same width. However in the case where the width of dialog is actually smaller than the width of all buttons the button box still reserves the same size. It would be more appropriate if in this case the buttons would be smaller.
Created attachment 113319 [details] [review] Implement allocation < requisition differently This is a patch that implements the suggested change. The code is basically taken from Maemo Gtk and slightly modified.
Created attachment 113320 [details] Screenshot demonstrating the new behaviour
Created attachment 113392 [details] [review] Shrink buttons if allocation < requisition After more fiddling I removed the _get_homogeneous checks since button boxes are always by definition homogeneous and anything else breaks in too many ways. I left comments in the appropriate places instead. Now the button box in a dialog makes the buttons smaller but still as large as possible if all hoomgeneous doesn't fit in. I saw no way of solving the, probably rare, case of all buttons' minimum sizes being too much for the available space.
> Created an attachment (id=113319) [edit] > Implement allocation < requisition differently > > This is a patch that implements the suggested change. The code is basically > taken from Maemo Gtk and slightly modified. Thanks. For those of us working with the Maemo Gtk codebase, it'd help to point out what/why you modified things slightly. (In reply to comment #3) > Created an attachment (id=113392) [edit] > Shrink buttons if allocation < requisition > > After more fiddling I removed the _get_homogeneous checks since button boxes > are always by definition homogeneous and anything else breaks in too many ways. Part of the original patch is to enable switching between homogeneous and heterogeneous button box layouts, so removing the checks is a bad idea. Also "breaks in too many ways" is too vague a description to be useful. If you encountered actual breakage, please describe how to reproduce it and what you think should happen instead. Without that, we don't have the needed discussion basis to consider changes/fixes. (In reply to comment #2) > Created an attachment (id=113320) [edit] > Screenshot demonstrating the new behaviour Thanks, do you think you could also provide a test program to create a sample dialog demonstrating the new button box layout facilities? This'd be useful to have for gtk-demo, and also serve as a basis to consider development of an automated unit test for the new layout featurs.
(In reply to comment #4) > > Created an attachment (id=113319) [edit] > > Implement allocation < requisition differently > > > > This is a patch that implements the suggested change. The code is basically > > taken from Maemo Gtk and slightly modified. > > Thanks. For those of us working with the Maemo Gtk codebase, it'd > help to point out what/why you modified things slightly. This first version has only stylistic modifications, it was mainly meant to make it easier to follow coming changes. > (In reply to comment #3) > > Created an attachment (id=113392) [edit] > > Shrink buttons if allocation < requisition > > > > After more fiddling I removed the _get_homogeneous checks since button boxes > > are always by definition homogeneous and anything else breaks in too many ways. > > Part of the original patch is to enable switching between homogeneous and > heterogeneous button box layouts, so removing the checks is a bad idea. Also > "breaks in too many ways" is too vague a description to be useful. If you > encountered actual breakage, please describe how to reproduce it and what you > think should happen instead. Without that, we don't have the needed discussion > basis to consider changes/fixes. For that to work "homogeneous" would need to be TRUE instead of FALSE by default. The by far biggest problem is glade's way of saving default values. Other (external) widgets making assumptions can be there as well. I just don't see how to overcome this.
Created attachment 113522 [details] Test dialog > (In reply to comment #2) > > Created an attachment (id=113320) [edit] > > Screenshot demonstrating the new behaviour > > Thanks, do you think you could also provide a test program to create a sample > dialog demonstrating the new button box layout facilities? This'd be useful to > have for gtk-demo, and also serve as a basis to consider development of an > automated unit test for the new layout featurs. I attached a stripped down version of my test dialog. The dialog contains a horizontal button box, as implemented by GtkDialog, and an additional vertical button box. Currently the patch doesn't include any changes to VButtonBox, but I am working on applying the same logic to the vertical box. It still has an ugly bug, so I'll attach it once I have sorted that out.
(In reply to comment #5) > For that to work "homogeneous" would need to be TRUE instead of FALSE by > default. The by far biggest problem is glade's way of saving default values. > Other (external) widgets making assumptions can be there as well. I just don't > see how to overcome this. Right, i've spent some thoughts on this and have to say Glade should be improved to not save and forcefully apply widget default values that haven't been set by the user. For the property at hand, it might be best to leave homogeneous=FALSE the default for button boxes, the effects will be user visible but non-fatal, i.e. buttons would just start to shrink correctly, and no application should be programmatically broken.
> Right, i've spent some thoughts on this and have to say Glade should be > improved to not save and forcefully apply widget default values that haven't > been set by the user. Some historical background on this: glade does this because in the past, many properties in gtk had documented default values that were != their initial values. A lot of this has been cleaned up, with two major exceptions: 1) object-valued properties with non-NULL initial values, which simply can't be specified as defaults 2) inherited properties where the subclass has a different initial value, but doesn't reinstall the property with a changed default because gobject makes this too hard (you have to duplicate the full definition including nicks, blurbs, etc)
Created attachment 113767 [details] [review] Implement allocation < requisition, including vbuttonbox This is an update of the previous patch, now including changes to vbuttonbox to implement the same change for the vertical case.
(In reply to comment #7) > (In reply to comment #5) > > For that to work "homogeneous" would need to be TRUE instead of FALSE by > > default. The by far biggest problem is glade's way of saving default values. > > Other (external) widgets making assumptions can be there as well. I just don't > > see how to overcome this. > > Right, i've spent some thoughts on this and have to say Glade should be > improved to not save and forcefully apply widget default values that haven't > been set by the user. > For the property at hand, it might be best to leave homogeneous=FALSE the > default for button boxes, the effects will be user visible but non-fatal, i.e. > buttons would just start to shrink correctly, and no application should be > programmatically broken. I'm not sure what your idea is. If the property default is not changed, buttons will suddenly shrink all over the gtk landscape. I don't think this is desirable at all.
Created attachment 115994 [details] [review] allocation < requisition, incl vbbox, respect homogeneous - GtkBox::homogeneous defaults to TRUE - Now GtkHButtonBox and GtkVButtonBox actually respect the "homogeneous" property of GtkBox. so far by definition that property was ignored and always assumed to be TRUE for button boxes. - If homogeneous is FALSE, all buttons request their minimum size regardless of how much space is available. This change will result in seeing non-homogeneous buttons in existing glade applications. This needs to be fixed on the application side. I can come up with a migration note for the README if we agree that this is okay.
Created attachment 115995 [details] Updated test dialog This updated test has a "homogeneous" check box, to toggle the property on the button boxes for testing.
Created attachment 116123 [details] [review] allocation < requisition, incl vbbox, respect homogeneous, #2 Corrected patch, I accidentally modified GtkBox::homogeneous before when I really should be changing the default value of GtkButtonBox::homogeneous to TRUE which is what makes sense here.
Created attachment 144774 [details] [review] allocation < requsition, refactored for orientable I refactored the changes on top of the refactored orientable GtkBox. The test application works like before. I left out a few stylistic changes to reduce the size of the patch.