After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 170137 - Make alternative-button-order more automatic
Make alternative-button-order more automatic
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
2.15.x
Other All
: Normal normal
: Small feature
Assigned To: Todd Berman
Todd Berman
Depends on:
Blocks:
 
 
Reported: 2005-03-13 05:34 UTC by Federico Mena Quintero
Modified: 2014-01-25 02:33 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Patch (651 bytes, patch)
2009-02-02 23:54 UTC, Magnus Boman
needs-work Details | Review

Description Federico Mena Quintero 2005-03-13 05:34:07 UTC
Right now, gtk_dialog_set_alternative_button_order() must be called if a dialog
is to change its button order when the gtk-alternative-button-order setting is
turned on.  With this, the stock GTK+ dialogs work fine, but applications are
not likely to call the function to define an ordering.

It would be nice if turning on the setting meant that most dialogs get their
button order reversed.  Special dialogs which require a particular ordering
should call gtk_dialog_set_alternative_button_order() explicitly.

This is important, for example, when running GTK+ applications under a KDE or
Windows session.  They should have a button ordering similar to the surrounding
apps.  Right now only the stock GTK+ dialogs get reordered as no one calls
gtk_dialog_set_alternative_button_order().
Comment 1 Joachim Michaelis 2005-07-06 09:13:23 UTC
I agree with Federico that it is likely that the majority of developers using
GTK will not use the gtk_dialog_set_alternative_button_order() call. This is
rather unfortunate because a lot of the users who are not used to macintosh or
gnome, using an application with macintosh/gnome-style button ordering is very
frustrating (due to both reading order and habits.)

I would like to both stress the importance of this issue and suggest
implementing one of the following two solutions:

1) Make alternative_button_order the default for ALL other cases other than
Gnome and Macintosh, so that GTK based apps fit the surroundings.

2) Make some kind of configuration file or preferences setting that the user can
adjust run-level and have it as he likes.
Comment 2 Magnus Boman 2009-02-02 23:54:42 UTC
Created attachment 127803 [details] [review]
Patch
Comment 3 Magnus Boman 2009-02-02 23:55:14 UTC
Attaching a patch from  Benjamin Weber
From Novell bug: https://bugzilla.novell.com/show_bug.cgi?id=471765



GTK dialogues have the buttons ordered the opposite way round to the rest of
the world, meaning people used to using other desktop environments or windows
click the [Discard Changes] button instead of the [Save] button that is
normally in the same place, leading to lots of frustration and lost work.

There is a setting that can be put in the gtkrc to switch the button order to
be the same as the rest of the world (
http://developer.gimp.org/api/2.0/gtk/GtkDialog.html#gtk-dialog-set-alternative-button-order
). Unfortunately this hardly works for any applications as it seems it requires
the application developer to call gtk_dialog_set_alternative_button_order
manually to apply any settings, which few do.

There is a workaround which is simply to call
gtk_dialog_set_alternative_button_order every time a dialogue is created or a
button is added to a dialogue. That way the application dialogues follow the
user preferences regardless of what the application developer does.

Here's a patch http://bw.uwcs.co.uk/b/fixgtk.diff

and a screenshot of it in action

http://bw.uwcs.co.uk/b/gtk_vanquished.png


Reproducible: Always

Steps to Reproduce:
0. Add gtk-alternative-button-order=1 to gtkrc
1. Open a GTK application such as gedit
2. Modify a document
3. Click close
4. Note the "lose my work" button is still where the rest of the world has
save.
Actual Results:  
Dialogues do not follow button order setting.

Expected Results:  
Dialogues do follow button order setting.
Comment 4 Matthias Clasen 2009-03-25 18:33:52 UTC
I'm pretty sure that patch is not going to work as is, because gtk_dialog_set_alternative_button_order_valist is not going to tolerate unmatched response ids well, from my reading of the code.