Under macOS the generic about dialog, used by wxAboutBox() when there is more information than the native about panel can show, has no buttons at all, so Escape didn't close it: wxDialog only translates Escape into a click on the Cancel or OK button. Now Escape closes it in the same way as the title bar close button does.
Tested with VoiceOver on macOS 26: Escape closes the dialog, and the close button still works. The native about panel also closes with Cmd+W, which this dialog still doesn't do; should it do this too?
While testing this dialog with VoiceOver, I also found that only its static texts can be read: the collapsible panes (license, developers etc) and the website link are custom drawn generic controls under macOS, and VoiceOver can't see them at all, so users can't open the panes or read their contents. I think wxWidgets should probably do something better for accessibility of generic controls under macOS in general, but this dialog can be fixed mostly by using native controls there, e.g. a native disclosure button for wxCollapsibleHeaderCtrl, and I plan to do this in separate PRs.
https://github.com/wxWidgets/wxWidgets/pull/27057
(1 file)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@vadz commented on this pull request.
I'm not sure if this is correct: if "Esc" is meant to close even the dialogs without buttons under macOS, then it should be handled in wxDialog itself there. And if it isn't (I think you might need to use Cmd+. or something like this?), then we shouldn't do it here either. @csomor Any guidance would be appreciated!
I.e. this dialog shouldn't be treated specially.
> @@ -270,6 +270,16 @@ bool wxGenericAboutDialog::Create(const wxAboutDialogInfo& info, wxWindow* paren
sizerTop->Add(sizerBtns, wxSizerFlags().Expand().DoubleBorder());
}
+#else
This should be Mac-specific, right? As the other platforms do create the buttons.
Ideal would be to replace
#if !defined(__WXMAC__)currently used in this code with
#if defined(__WXMAC__) // Mac typically doesn't use OK buttons just for dismissing dialogs. #define wxUSE_BUTTONS_IN_ABOUT_DIALOG 0 #else #define wxUSE_BUTTONS_IN_ABOUT_DIALOG 1 #endif
and then use
#if !wxUSE_BUTTONS_IN_ABOUT_DIALOG
here.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
I've tested the native About panel of TextEdit under macOS 26, and neither Escape, Cmd+. nor Cmd+W close it: Escape does nothing and the other two just beep. So it looks like the native behaviour is to not close such windows from keyboard at all, and I agree that this dialog shouldn't be treated specially. VoiceOver users can still close it using its close button. I'll close this PR, unless Stefan thinks Escape should close dialogs without buttons in general.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@trypsynth I've tested under several systems, and the TextEdit About Dialog and the "About this Mac" Finder Dialog were closing on most of them with Escape and Command-W. I'm still looking whether I can find some authoritative answers in a Human Interface Guideline.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@vadz in general the behavior would have to be for very simple dialogs with no buttons and no entry fields of any kind, kind of "transient" pure information presentations. I agree that we should lift this up, but I don't know whether we can do this via some kind of introspection or whether we would have to add some kind of property on the dialog instance that triggers this behaviour
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Thanks for testing! I should have mentioned that I was running VoiceOver during my test, and it does intercept some keys, so it's quite possible that it swallowed Escape and that the native dialogs do close with it, as you've seen.
For the general solution, I'd rather have it opt-in than based on introspection: a dialog without any buttons today could get a checkbox or a text field tomorrow and silently lose the ability to be closed with Escape, which would be hard to notice. Something like a wxDialog style or a method saying "this dialog is only informational and can be dismissed with Escape or Cmd+W" seems safer, and the generic about dialog would then use it under macOS.
I'd be happy to implement it once you decide which way you prefer.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()