Properties tab has no ‘tab order’

• Mar 6, 2023 - 05:14

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.


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 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 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 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 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 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 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.


In reply to 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.

Do you still have an unanswered question? Please log in first to post your question.