Allow space to control playback after clicking elements that do not require keyboard focus.
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
that other issue gets better notated as #37061: Spacebar doesn't works after changing BPM value in Inspector ("[#37061]")
+1 - the mixer 'stealing' the spacebar play/pause function gets me all the time.
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.
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.
I agree that it would be very worth to get the space bar fixed to play-pause.
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.
In reply to (No subject) by Jojo-Schmitz
Is there a chance to get this fixed?
It disturbs a lot when the space key fails to react for start/pause.
It happens frequently that one continously switches between mixer panel and score, and then can't start or stop the play. It is even more disturbing that the changes done outsinde the score (e.g. mute/solo) are un-done by the space key. Why not permamently lock the space key to the pause function, regardless of the focused panel?
(perhaps also has to do with this issue? https://musescore.org/en/node/35576)
You mean #35576: Space bar shortcut does not work when play panel window is in foreground, I guess ;-)
Fixed since 7 years, ever since MuseScore 2.0
The mixer has been completely redesigned for MsueScore 4, and for that matter, so has the entire UI. So, the Mute button in particular button no longer takes keyboard focus. But I wouldn't be surprised to see some other cases where some other button now does. So, it's worth keeping the issue open to remind people concerned with this to check in MuseScore 4 builds for themselves.
In reply to The mixer has been… by Marc Sabatella
https://musescore.org/en/node/318872#comment-1169992
The original issue is definitely fixed. If you are seeing some special case where it is not working, that might be a new issue. Please follow up on the forum with sample score and precise steps to reproduce the problem. Then if others can confirm by following your steps, the next step would be to open an issue in GitHub,
Are we speaking of the same issue?
No sample MuseScore 4 document required:
On MacOS Ventura 13.1:
• File>New Score
• Press Done
• In the Mixer press Mute or Solo
• Press the spacebar
The spacebar keystroke doesn't not start or stop playback. Instead it toggles the Mute or Solo button.
scorster
In reply to Are we speaking of the same… by scorster
Weird. For me with Musescore 4.0.1.230121751 on linux, this no longer happens. Your instructions say to "Open the Mixer" but mine is already present and docked. No combination of mixer open/closed or docked/undocked when the program starts makes this happen for me. What OS?
In reply to Weird. For me with Musescore… by clepsydrae
> Your instructions say to "Open the Mixer" but mine is already present.
Good point. I last used the Mixer undocked. And now it appears as a thin vertical rectangle with no controls visible, maybe a half inch wide on my second monitor. (Perhaps another bug?) Since I needed to move and resize the Mixer to reveal the channel strips, that left me with the "sensation" of having to open it. I'll update my steps to replicate.
What OS are you using?
In reply to Are we speaking of the same… by scorster
Since others cannot reproduce this new bug, we really do need more information. Even if seems like it couldn't be score related, we just don't know what yet. It could well depend on how many channels there are - whether they all fit on the screen or not, whether effects are enabled, any number of variables we just can't know.
So please do attach the score, and also a screen recording, so we can see also how things are laid out - how you are opening the mixer, whether it is docked or not, etc.
The fact that there are two monitors involved is also good new information that may prove relevant - see if you can reproduce the issue with a single monitor.
In reply to (No subject) by Marc Sabatella
Oops i see now that you are on MacOS Ventura 13.1. Hopefully someone with a Mac can test.