GNOME Bugzilla – Bug 735119
inconsistent order of close/help buttons
Last modified: 2014-08-29 01:29:47 UTC
In the "preferences" window, the buttons are close then help; in the "edit profile" window, the buttons are help then close. (this is 3.13.90)
What distro, desktop environment, theme are you using? To which side are these buttons aligned? I have Ubuntu Trusty with its default Unity desktop (but tried in kde and icewm too), and only vte/gnome-terminal upgraded to 3.13.90. I can't reproduce your bug. In both of these windows, Help is in the bottom left, Close is in the bottom right corner for me.
It was during a smoketesting session of 3.13.90 (<https://download.gnome.org/teams/releng/3.13.90/versions>). preferences.ui: <action-widgets> <action-widget response="-7">close_button1</action-widget> <action-widget response="-11">button1</action-widget> </action-widgets> profile-preferences.ui: <action-widgets> <action-widget response="-11">helpbutton2</action-widget> <action-widget response="-7">closebutton2</action-widget> </action-widgets> I opened both file with glade-previewer and they look fine with GTK+ 3.12 (help on the bottom left, close on the bottom right), but incorrect with GTK+ 3.13 (both button on the bottom right, not in the same order). I'm reassigning to GTK+.
Just as bad is that the alignment/padding has been broken. Previewing the profile-preferences.ui file with glade-previewer under gtk 3.8 is fine, but under master the padding between the content (notebook border) and the dialogue buttons is reduced, and on the right bottom side the buttons stick out a few pixels over the content border.
If indeed Gtk+ changed the order of the buttons and broke the alignment/padding, this sounds like a release blocker to me. Does anyone with better insight agree? If so, please bump the priority/severity :)
The ui files for those dialogs are simply inconsistent. Both pack their action widgets manually in the action area. preferences.ui puts the help button at position 1 and the close button at position 0, while profile-preferences.ui does it the other way around.
So, you say that Gtk+'s behavior was buggy so far, accidentally resulting in the consistent layout for gnome-terminal? If gnome-terminal's layout changed, probably many other apps (not just Gnome, also third party Gtk+ apps) will also change their layout upon a Gtk+ upgrade. IMO such a move is only okay if Gtk+ can clearly defend that it used to be buggy and it's doing the right thing now.
GTK+ behavior changed. Dialogs have seen a significant overhaul this cycle, and we've tried very hard to keep most reasonable things working - which is really not easy since there are far too many ways to construct and populate dialogs. If you can clearly define what kind of magic behavior GTK+ had before that made append ("Help"); append ("Cancel"); come out the same way as append ("Cancel"); append ("Help"); then we can possibly look at preserving it. But I don't think it would be outrageous to just say: you get the order you asked for. In any case, gnome-terminal would be best off to put its buttons in the order it wants them in.
Fair enough, thanks for the explanation! Assigning back to gnome-terminal. ChPe, could you please take care of this? I don't want to submit a fix blindly, nor upgrade my Gtk just to be able to test this.
Created attachment 284340 [details] testcase glade
This *is* a gtk+ bug, re-assigning back. The problem is that gtk master doesn't set the Help button as secondary child of the button box automatically anymore (which it used to do based on the response being GTK_RESPONSE_HELP). Ie see the attached testcase .glade file: using gtk 3.8 the help button is at the left, while on gtk master it is on the right (not secondary).