Bug 8390 - Dialog buttons have incorrect order on Windows
Summary: Dialog buttons have incorrect order on Windows
Status: CONFIRMED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: 4.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Cody Russell
URL:
Depends on:
Blocks:
 
Reported: 2012-11-13 20:17 UTC by Duncan Mak
Modified: 2015-02-23 12:42 UTC (History)
7 users (show)

Tags: ui-refresh
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 8390 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Duncan Mak 2012-11-13 20:17:47 UTC
The OK button is the right-most, when Cancel should be there instead.
Comment 1 Duncan Mak 2012-11-13 20:19:51 UTC
Also on Windows:

In the top bar, MenuItems are too far apart

Menu items are missing mnemonics

Problem might be in the gtkrc.
Comment 2 Mikayla Hutchinson [MSFT] 2012-11-14 16:29:56 UTC
It looks like our custom gtkrc is missing the settings:
http://developer.gnome.org/gtk/2.24/GtkSettings.html#GtkSettings--gtk-enable-mnemonics
http://developer.gnome.org/gtk/2.24/GtkSettings.html#GtkSettings--gtk-alternative-button-order

And has incorrect spacing for the menubar widget.
Comment 3 Alex Corrado [MSFT] 2012-11-15 16:28:34 UTC
The mnemonics and MenuItem padding are fixed in 67de5c6.

That commit also adds "gtk-alternative-button-order = 1" to the gtkrc, but it doesn't seem to have any effect.
Comment 4 Bojan Rajkovic [MSFT] 2013-01-10 23:34:03 UTC
Is this fixed in recent builds with the new GTK+ bits?
Comment 5 Mikayla Hutchinson [MSFT] 2013-01-11 18:53:20 UTC
Nope, I can still reproduce it. Not sure why gtk-alternative-button-order no longer works.
Comment 6 Mikayla Hutchinson [MSFT] 2013-05-06 17:56:02 UTC
Mitch, Aleksander, can we bump the priory on this one?
Comment 7 Aleksander Morgado 2013-05-07 04:05:32 UTC
Will take a look at it.
Comment 8 Aleksander Morgado 2013-05-07 04:21:24 UTC
In which kind of dialog is this issue happening? If this is a custom dialog with manually added buttons, did you also explicitly call   gtk_dialog_set_alternative_button_order () to specify which the alternative order is?

From a quick look running gtk-demo, gtk-alternative-button-order correctly applies the alternative order in windows by default.
Comment 9 Michael Natterer 2013-05-07 04:50:47 UTC
It also works correctly on Linux and OSX, so there is no platform bug
going on. I can only agree with Aleksander's question: do the affected
dialogs call gtk_dialog_set_alternative_button_order()?
Comment 10 Mikayla Hutchinson [MSFT] 2013-05-07 14:28:23 UTC
Oh, this might be our mistake. I don't think we realized that the alternative button order setting was not applied to dialogs automatically when set by the theme.
Comment 11 Michael Natterer 2013-05-07 17:59:01 UTC
That's because it's more complex than just reversing the order of
all buttons, e.g.:

Reset, Cancel, OK

turns into

Reset, OK, Cancel

NOT into

OK, Cancel, Reset
Comment 12 Mikayla Hutchinson [MSFT] 2013-05-07 20:43:11 UTC
Hm, that's not going to be fun to fix. We have some high level APIs for creating and running dialogs from a couple of message strings and a list of buttons. We may need to extend those APIs and audit all the callsites.
Comment 13 Michael Natterer 2013-05-28 09:50:59 UTC
I am not the expert on the Windows HIG, but I believe that a simple hack
which swaps the last two buttons if they are "Cancel" and "OK" would cover
a lot of cases already, and be definitely more correct than having the
button area end in "Cancel, OK".
Comment 14 Michael Natterer 2013-06-06 10:13:33 UTC
I am not so sure any longer about what I wrote in comment 11.

According to this extremely hard-to-read document:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511268.aspx

I *think* the button order should be simply flipped from what
we're used to on OSX/GNOME, but I distinctly remember a document
describing what I wrote above, but that was back in the time when
GNOME switched button order and I ported GIMP, things may have
changed in the meantime.

The MSDN link above really  lacks a comprehensive list of correct button
order examples.