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 74669 - Add public setting for button ordering
Add public setting for button ordering
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.0.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 138277 166793 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-03-14 17:39 UTC by Owen Taylor
Modified: 2011-02-04 16:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
a patch (7.92 KB, patch)
2004-09-29 02:22 UTC, Matthias Clasen
none Details | Review

Description Owen Taylor 2002-03-14 17:39:05 UTC
Whether or not the No/Yes ordering is right in the GNOME
context, it's clearly wrong when running GTK+ apps within
Microsoft Windows, or KDE.

Since people write GTK+ apps for such contexts, we need
to:

 - Add a GtkSetting for this preference
 - Add an API function to get the value of this setting
   (with a note to connect to notify::gtk-dialog-ordering
   on the settings object for notification in the docs.)
 - Make the standard GTK+ dialogs obey it

I have no illusions that most apps will obey this property,
or that almost any apps will change on the fly ... so
it probably shouldn't be added to, say, the GNOME control
center, but at least we need to be able to get apps designed
for windows, on windows correct in this regard.
Comment 1 Gregory Merchan 2002-11-29 05:28:06 UTC
Here is a summary of the Microsoft guidelines. There are three kinds
of secondary windows with dialog-like buttons: property sheets,
message boxes, and dialogs.

Property sheets
   |       [   OK   ] [ Cancel ] [ Apply  ] |

  No Help button, it goes next the the window frame's close button.
  Optional Reset button, but no placement specified.

Message Boxes
  When the user can decide:
    nothing                       |              [  OK  ]              |
    whether to continue           |       [   OK   ] [ Cancel ]        |
    how to continue               |         [ Yes  ] [  No  ]          |
    whether and how to continure  |  [   Yes  ] [   No   ] [ Cancel ]  |
    to stop progress              |              [ Stop ]              |

  Replace Cancel with Stop if what has been done cannot be undone.
  Replace Yes, No, or OK with a specific command (e.g., Save) when
ambiguous
  Optional Help button, but no placement specified.

Dialogs
  OK and Cancel always together when both are present as such. (I.e., if
   the OK response is the button labelled Print, this doesn't hold.)
  Default button always first from left to right or top to bottom in a
group,
   but a sole button outside of the group may appear.
  The guidelines show some example dialogs, but there's no more order to
   be discerned from them.

Source: http://msdn.microsoft.com/library/en-us/dnwue/html/ch09a.asp
et seq.
Comment 2 Soren Sandmann Pedersen 2004-03-28 13:48:52 UTC
*** Bug 138277 has been marked as a duplicate of this bug. ***
Comment 3 Joachim Michaelis 2004-07-02 16:14:07 UTC
I would very much like to stress the importance of getting this issue solved. I
have no idea why people are suddenly going against the obvious standards, but i
suspect the loud nature of macintosh users to be the cause. I will not argue
whether this or that is right or wrong here, but one thing remains: Going
against a long lasting standard should be something the user should be able to
disable easily without the need of recompiling. In fact, i think the default
setting should follow the above guidelines.
Comment 4 Sven Neumann 2004-07-02 16:34:04 UTC
What "standard" are you refering to? Got a link to that document perhaps?
Comment 5 Kevin Ar18 2004-07-02 16:43:35 UTC
I believe that Joachim was just reacting to some ugly comments made by other
people when I asked about someone who might be willing to add a patch for this
(I called it a bug for lack of a better term).

I don't think there's a need to take this any further.  Comment #1 and #2 pretty
much covered the details and the reasons.
Comment 6 Sven Neumann 2004-07-02 17:06:12 UTC
Sure, I wasn't questioning that it would be good to resolve this in the way that
Owen suggested earlier. Of course it's rather unfortunate that this wasn't done
when the button order was changed and everyone had to touch their apps. Now if
this setting is added, it is unlikely that a lot of apps will obey it.
Comment 7 Jeff Waugh 2004-07-26 00:49:57 UTC
Surely this should be closed by now, given that it's an issue of design, not of
order or preference...?
Comment 8 Sven Neumann 2004-07-26 01:01:48 UTC
Why shouldn't it be an option? GTK+ tries to be a cross-platform toolkit and it
works rather well as such. One of the issues that ports face is button ordering
and a way to workaround this problem is to make it configurable. Some
applications will decide to go for that option and it would certainly be better
if they could share a preference that is set for all GTK+ applications.
Comment 9 Matthias Clasen 2004-09-29 02:22:13 UTC
Created attachment 32049 [details] [review]
a patch

Here is a patch along the lines of owens initial comments.
Comment 10 Matthias Clasen 2004-10-25 05:43:45 UTC
2004-10-25  Matthias Clasen  <mclasen@redhat.com>

	Add a public setting for button ordering (#74669, Owen Taylor)
	
	* gtk/gtksettings.c (gtk_settings_class_init): Add a 
	gtk-alternative-button-order setting.

	* gtk/gtkdialog.h: 
	* gtk/gtkdialog.c (gtk_alternative_dialog_button_order): A 
	getter for the alternative button order setting.
	* gtk/gtkdialog.c (gtk_dialog_set_alternative_button_order): 
	New function to install an alternative button order for a 
	dialog.

	* gtk/gtkfilesel.c (gtk_file_selection_init): 
	* gtk/gtkfontsel.c (gtk_font_selection_dialog_init): 
	* gtk/gtkmessagedialog.c (gtk_message_dialog_add_buttons): 
	* gtk/gtkcolorseldialog.c (gtk_color_selection_dialog_init): 
	* gtk/gtkfilechooserdefault.c (location_popup_handler): 
	Set up an alternative button order.
Comment 11 Richard Hoelscher 2005-02-09 16:03:59 UTC
*** Bug 166793 has been marked as a duplicate of this bug. ***