Allow space to control playback after clicking elements that do not require keyboard focus.

• Jan 5, 2021 - 20:14
Reported version
3.x-dev
Type
Ergonomical (UX)
Frequency
Few
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project

Currently, if any element has focus, spacebar will not work to start/stop playback. This is a high-friction user experience when, for example, you mouse over to the mixer and mute a track. You then hit spacebar to start playback and... the track unmutes. It's unexpected, and not particularly useful.

There are probably good accessibility reasons to have this type of behavior available (?), but I would suggest that for most users this is a frustrating experience, so it would be great if there was at least an option to always send spacebar keypresses to the main score window (unless they are consumed, obviously, in e.g. a text field.)

This is a very common pattern in DAWs, video editors, etc: the spacebar is a near-universal key for playback start/stop, and in almost all software it maps to that function from most parts of the program. I believe MuseScore would benefit greatly from adopting this pattern.

There are other bug reports related to this (e.g. https://musescore.org/en/node/37061 ) but they were a bit more specific, so I filed this general one -- I hope that's OK.


Comments

Title Map spacebar to start/stop, regardless of focus Allow space to control playback after clicking elements that do not require keyboard focus.

I strongly disagree with the notion that MuseScore should ever disobey standard UI and accessibility principles. If an object has keyboard focus, it absolutely must accept keyboard input normally. Anything else would be disaster.

Howerver, that said, there's no particular reason that clicking the Mute button in the mixer need transfer keyboard focus there. So that's the solution to the issue - don't break what happens when keyboard focus is present, just change which actions actually transfer keyboard focus. That is, to me, the solution.

Yeah I'd personally be fine with disabling focus for the mute button, but I would wonder if someone somewhere needs that accessibility?

There are a few places besides that which invisibly steal focus, e.g. a volume fader on the mixer, or empty background space in the mixer pane, selecting an item in the score palettes, etc. (aside: it doesn't happen for the play panel or inspector, just the mixer and pallettes...)

Of course one way to deal with it is to say "if the space bar keypress event is not consumed, pass it up the widget tree", and if the top of the tree receives it, it starts/stops playback. I.e. all accessibility support can be maintained as normal, and unused space bar events (or any other shortcut) can still function as expected. (Of course this alone wouldn't solve the mute button, which currently consumes a spacebar.) For example, the volume fader in the mixer can be raised/lowered with the arrow keys, which is presumably why it takes focus, but spacebar does nothing there, so it could be passed up the tree.

I'd still vote for an advanced non-default pref that says "empower spacebar to start/stop everywhere unless in a text field" or similar, but the above in conjunction with disabling keyboard focus for the mute button would be great.

Workaround No Yes

In general, people who need the mute button to be keyboard-accessible wouldn't be transferring focus to it by clicking it to begin with - it would be via keyboard controls (eg, Tab, cursor keys, etc). And right now the Mixer is quite a mess, I don't know that it is possible to even reach the mute button via tab. So to me it doesn't hurt to just not allow the mute button to take keyboard focus on click, since it's inaccessible to blind users anyhow as far as I can tell. Probably that's doable by setting the property on the button appropriately. Still, eventually there needs to be a major redesign of the whole thing, and I'm not so sure it's worth messing with meanwhile.

But yes, the normal way a GUI works is more or less as you describe. The problem is, the mute is in essence a toggle button, and toggle buttons are operated with Space. So if keyboard focus is on the button, Space needs to operate it. But again, it's perfectly acceptable to have clicking not transfer focus, as far as I know. For instance, I just did a super-quick check using the "Workaround" toggle on this page as presented in Chrome, and it doesn't transfer keyboard focus. That is Clicking the checkbox then pressing Space does not toggle it. Space scrolls the page just as it does if focus is pretty much anywhere outside a text box. And even within MuseScore, clicking toggle buttons in the Inspector doesn't transfer keyboard focus either - Space starts playback as expected.

You can tab to the mute button (at least on linux), but the overall focus cycle is 78 tabs long (on one simple project I have), most of which are invisible, and they seem to be in relatively random order (e.g. the cycle enters and leaves the mixer pane several times.) So yeah, agreed, it's not in a very usable state right now, AFAICT.

Disabling focus for the mute button sounds good to me, but I just hope a similar change can happen for the background of the mixer panel, etc., which also takes keyboard focus. And it'd be nice if clicking on a volume fader didn't have the same issue, hence the suggestion to percolate the spacebar in those kinds of cases.

It also disturbs when muting an instrument in the mixer and then trying to start again with space-bar, the last change in mixer is un-done by the space-bar. So the lost focus (from play/pause) is one disturbance, the un-intended new focus (to mixer) is a second disturbance.