Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
The OK button is the right-most, when Cancel should be there instead.
Also on Windows:
In the top bar, MenuItems are too far apart
Menu items are missing mnemonics
Problem might be in the gtkrc.
It looks like our custom gtkrc is missing the settings:
And has incorrect spacing for the menubar widget.
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.
Is this fixed in recent builds with the new GTK+ bits?
Nope, I can still reproduce it. Not sure why gtk-alternative-button-order no longer works.
Mitch, Aleksander, can we bump the priory on this one?
Will take a look at it.
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.
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()?
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.
That's because it's more complex than just reversing the order of
all buttons, e.g.:
Reset, Cancel, OK
Reset, OK, Cancel
OK, Cancel, Reset
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.
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".
I am not so sure any longer about what I wrote in comment 11.
According to this extremely hard-to-read document:
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