Export can't be run by clicking Enter key in the Export dialog

[abariska]

Issue type

Other type of issue

Steps to reproduce

1. Open any score
2. Go to Export dialog and choose any type of export
3. Press Enter

Screenshots/Screen recordings

https://github.com/musescore/MuseScore/assets/101250347/682cbd67-303d-42c1-909e-abc5cbae13cc

MuseScore Version

OS: macOS 13.6, Arch.: x86_64, MuseScore version (64-bit): 4.2.0-232900304, revision: github-musescore-musescore-7091ae6

Regression

Yes, this used to work in MuseScore 3.x and now is broken

Operating system

macOS 13

Additional context

[Jojo-Schmitz]

In Mu3 for some stupid reason "Cancel" is the default button, so it doesn't really work there either, unless you change the default export format.

The issue title is wrong though, of course can you click the enter button and it works.

[abariska]

@Jojo-Schmitz there's a question which button should be focused by default

[Jojo-Schmitz]

"Do" should be reached via Enter, "Don't" by Esc, IMHO, by default .

And esp. if, like here, "Do" is highlighted already.

[cbjeukendrup]

I think this is quite related to #12222

[Eism]

No, this is not related to #12222 All we need is to focus on the first button from the ButtonBox instead of focusing on the first element of the export scores list

[cbjeukendrup]

@Eism I'm not sure if I agree. My expectation is:

• Enter / Return always does the same as the "accent button", regardless of what's focused
• Spacebar "clicks" the focused button.

At least, that is default behaviour on macOS. Not sure if that's what we're aiming for.

[Jojo-Schmitz]

IMHO it is what we're aiming at. Or should be 😉

[Eism]

Ok, I got it. I missed point 2, changing focus from the accent button. Yes, this is related to #12222.

[cbjeukendrup]

Idea about implementation, inspired by Qt: We could give StyledDialogView a signal called acceptRequested and a signal called rejectRequested. Pressing Esc triggers rejectRequested and pressing Enter triggers acceptRequested. Additionally, clicking Cancel and OK (or Export… or whatever is the accent button in the dialog in question) also trigger these signals respectively.

Then, in each dialog, we add onRejectRequested and onAcceptRequested signal handlers, where we put logic for closing the dialog and handling the OK button press; i.e. we move the logic from the onClicked signal handler in the Cancel and OK button to the onRejectRequested and onAcceptRequested signal handlers in the dialog.

Is that a good idea?

[shoogle]

This is basically correct:

• Enter / Return always does the same as the "accent button", regardless of what's focused
• Spacebar "clicks" the focused button control.

However, when another button has focus ("Cancel", "Select all", "Clear selection"), the blue accent should move to that button in addition to the focus rectangle, and Enter/Return should press that button instead of "Export".

When any non-button has focus (e.g. "Main score" checkbox, "Format" dropdown), the blue accent should return to the default button ("Export"), and Enter/Return should press the default button again.

So Enter/Return always presses the accented button, but the accent moves to other buttons when they have focus. It returns to the default button when any non-button has focus. You can see this behaviour in MuseScore 3, and in Microsoft programs such as Notepad (File > Page Setup), Wordpad (File > Page setup), and File Explorer (three-dots > Options).

[cbjeukendrup]

However, when another button has focus ("Cancel", "Select all", "Clear selection"), the blue accent should move to that button in addition to the focus rectangle, and Enter/Return should press that button instead of "Export".

Hm, that seems to be how Qt and Windows do it, but not how macOS does it. I find it a bit janky to be honest. But maybe we can make this OS-dependent.

[shoogle]

I'm inclined to follow Microsoft for shortcuts and keyboard navigation. It's one of the few things they do better than Apple.

Some quirks of macOS for keyboard users (at least of Big Sur, which is the version I have access to):

• Not possible to right-click via the keyboard.
• Menus & dialogs don't support mnemonic access keys.
• Useful settings are hidden unless you Option+click on them.
• Tab navigation is disabled unless you explicitly enable it via System Preferences > Accessibility.
• Some accessibility-related shortcuts advertised in System Preferences don't actually work.
  • E.g. Ctrl+F8 to focus the "status menus" (apparently this means the bluetooth, wifi, battery, clock area in the upper-right menubar, but the shortcut does nothing for me).

Admittedly VoiceOver is pretty good, but it doesn't read object descriptions (just their names, though this might be a Qt problem). Also, some keyboard functionality is only available while VoiceOver is running, which isn't friendly to keyboard users who are not visually impaired.