Properties tab has no ‘tab order’
E.g. if you are editing a vertical frame and the cursor is in the Left Margin box and you press TAB, instead of moving to the Right Margin box next to it, focus is shifted to the tab belonging to the score.
This is counter-intuitive and makes using the keyboard impossible.
Comments
MuseScore implements a newer model of keyboard navigation where it isn't all about Tab anymore. Instead, it's hierarchical, with F6 being the top level to move from panel to panel, Tab to move between individual groupings of controls within the panel, and then cursor keys moving about within the grouping. This allows you to move about the interface much more quickly than having to Tab through each and every control all the time. But, it does take a little getting used to.
In reply to MuseScore implements a newer… by Marc Sabatella
Is this documented somewhere? It seems very unintuitive.
Tab doesn’t just move within one group of controls, it also moves you out of the panel entirely.
Cursor keys also change values up and down as well as sometimes moving you down to the next control. Ambiguity is not good.
Left / Right does not move to different sub-sections of the panel either.
It might turn out to be a great new model, but it looks broken to me at the moment.
Maybe it works differently for you? Could you try editing the values of a vertical frame using the keyboard? For me, it’s completely impossible.
In reply to Is this documented somewhere… by Moilleadóir
It's documented in the Handbook, in the accessibility section at least but perhaps elsewhere as well.
And yes, Tab does also take you between panels, so it does do the full circuit of the UI - but within each group, cursor keys move between controls, and only within that group. For spinboxes, you need to use left/right after accepting the value.
As I said, it takes some getting used to this newer system, and no doubt refinement will come over time, but overall it's more efficient.
In reply to It's documented in the… by Marc Sabatella
No, Tab does not cycle for me. It dead-ends (as I said) with the score selected. After that, Tab and Shift-Tab do nothing. F6 does.
I know you’re trying to be helpful, but it feels like you’re not listening.
After some more experimentation it seems that the hidden extra requirement (not mentioned in the Handbook) is that you have to press Esc in any editable field before you can then use an arrow key to move to the next one. So, two key-presses instead of one.
Absolutely not more efficient.
Edit: also if the mouse cursor is over certain widgets, arrow keys don’t work at all. Perhaps the focus is shifted.
In reply to No, Tab does not cycle for… by Moilleadóir
I'm sorry we're having trouble communicating. I am absolutely trying my best to to help, but it's true I'm not always understanding exactly what the problem is you are perceiving. It would be best to attach a score and give precise steps to reproduce the problem. Could well be there is one specific control for which the accessibility isn't working as expected and I simply haven't tried that control. Overall, though, it definitely works as I am saying. We have a sizable number of blind musicians successfully using MuseScore 4 using keyboard alien - no mouse whatsoever - so it definitely does work in general.
But, now that you describe a somewhat more specific issue of Tab getting stuck on the score (you hadn’t mentioned that previously that I can see), I did manage through some trial and error to find a specific sequence of steps that reproduces this, and then indeed, you need F6 to move forward. That's a bug, so please report it on GitHub so it can be investigated and fixed. Please be specific about the exact sequence of clicks/keystrokes that reproduces the problem, as it is by no means obvious and thus far as mentioned no one else had managed to stumble on it to my knowledge.
In reply to No, Tab does not cycle for… by Moilleadóir
And yes, as mentioned, in spinboxes you need to accept the value first, either Enter or Esc. So that specific operation takes an extra keystrokes, but virtually everything else takes fewer, so still a win overall. This is easily measured in usability tests by counting keystrokes for various common tasks. But like I said, stiklkl room for further refinement, and behavior on spinboxes specifically is indeed one of those areas, so by all means, I encourage you to open an issue on GitHub regarding that. Probably it makes sense to use Tba any time a spinbox is encountered.
In reply to No, Tab does not cycle for… by Moilleadóir
FWIW, I have filed an issue regarding Tab behavior with the title frame selected. It turns out everything about the properties panel is a red herring with respect to that particular aspect of the issue - it's as simple as Tab not functioning as you might expect with a frame selected. And same for barlines, lines, stems, or any element with handles: Tab instead cycles through the handles. This was true in MU3 as well and it was a much more serious problem. Now, we have F6 to break you out of the cycle and move focus through UI. So I'm not convinced it needs to be fixed. but it would be good to have clarification.
See https://github.com/musescore/MuseScore/issues/16738
In reply to MuseScore implements a newer… by Marc Sabatella
The problem with circumventing the standard keyboard navigation model of an operating system is that it fights with muscle memory, and use of other programs at the same time. Even getting around the form for creating a new score drives me crazy as it requires completely different keys to everything else I use.
Ironically the Accessibility section of the handbook is very hard to navigate to as the different versions of the handbook are not connected, and I find myself having to edit the URL to change the version number most of the time.
In reply to The problem with… by memeweaver
I'll also add that most of the dialog boxes in the program e.g. Style, Page Settings, Tuplets, System Breaks, ... plus all the standard system dialogs for Open, Save etc still use the tab model for moving between fields.