Keyboard accelerators for all menus/dialogs

• May 20, 2021 - 00:19

For operations that you perform regularly, being able to use the keyboard to select menu options and dialog controls is critical (it can mean the difference between something taking 1-2 secs and taking 15-20).
But I've noticed that the RH context menu has no keyboard accelerators, and nor does the "Select Notes" dialog, among others.
Any reason they shouldn't be added?


Comments

For the record, you can use the key board in the standard way to navigate menus - eg, Alt+F to open the file menu, or whatever key is configured on your particular keyboard OS to open context menus. Any command that is defined to accept shortcuts works, but lots of things aren't current;y implemented that way, including individual options and combinations of options with dialogs (eg, it would not be feasible to have shortcuts for all 10,000 or so possible combinations of the checkboxes in the Select / More dialog).

In reply to by Marc Sabatella

There's not that many controls in "select more", I don't see why they couldn't all have keyboard accelerators. Not sure what you mean by 10000 combinations - I just expect a key for each checkbox, then I can toggle them quickly by typing those letters out. Pretty sure the MS UI guidelines at least make it clear you should strive to do this where possible, dunno about MacOS (one reason I don't use Macs is because there's too many operations that seem basically impossible without a keyboard).

In reply to by Dylan Nicholson1

I was thinking you meant, a shortcut you can access directly from the score, not within the dialog. I get now you are actually talking about what are more generally called "mnemonics" - the underlined letter one often sees within a menu or dialog. As mentioned, those are possible but have translation issues. It's easy enough to add them and perhaps future versions of MuseScore will add more. But for the record, we do support standard keyboard navigation in most dialogs, eg, tab to select a box then space to toggle it.

FWIW, I just made up the number 10,000 for the number of combinations that would be needed to allow it to be done from the score, but I got curious and decided to do the math. With a note selected, there are 13 different checkboxes. Each can be selected or not. 2^13 = 8192. Plus the 4 radio buttons, it's that times 4 = 32,768 different actions that can actually be performed here.

With keyboard accelerators we (node to) stay on the careful and conservative side, as these are a pain for translators, they need to get adjusted to every of the available languages and in a way that avoides conflicts.

In reply to by Jojo-Schmitz

If you look at how MS apps are in Japanese etc you'll see they reuse the English accelerator letter but show it in parentheses after the command text.
Agreed that this makes them less useful or easy to remember but we're all used to ctrl+v for paste (not an accelerator I know but it demonstrates keyboard shortcuts can be useful even if it uses a letter not in the command name).
At any rate there's surely enough English users that it'd be useful to do even if just for the English version initially.

In reply to by Jojo-Schmitz

Yes but we're not taking anything away from such users, they just have to wait a little longer until someone adds the accelerators for the latter languages. If you were going to insist that every single change to the UI (including such minor enhancements) had to be translated to all of the 60+ supported languages before it could be released then how do you ever get anything done? Do you never do A-B testing?
And I'm curious - if it's true there's a significant percentage of users that would struggle to use a version with only English menu commands/dialog text, how do they get support? Personally I can't imagine trying to use the internet for help on using software without a reasonably decent grasp of English!

In reply to by Dylan Nicholson1

If they are in on the English "orginal" texts, they are in in every translation. At frist, i.e. when still untreanslated, in the English version, including the accelerator. Here already the first conflict with other, already translated strings, can occur.
The problem is to find a proper translation for not only the menu text, but also for the accelerator. the former is easy and normal, the latter though requires the translator to know the context and which other accelerators are in the vonsinits, to make a decision which of the letter of the translation to mack as an acceleralor while ensuring its uniqueness.

In reply to by Jojo-Schmitz

Sure, but that conflict is not a major drama - at worst it means you now have to hit enter after the accelerator, or hit the accelerator letter twice then enter. And it is a reasonable argument for keeping accelerators the same between languages, or even just using the default automatic accelerator behaviour (which MuseScore doesn't seem to honour for whatever reason).

In reply to by Dylan Nicholson1

As I tried to explain in great detail you can't use the same accelerators in all languages!
The letter that is used for it in English more often than not is not part of the translated term.
And an automatic choosen accelerator is something none of the libraries MuseScore uses has to offer. You can't 'blindly' just take the firsat character either, not even in English, "Save" and "Save As" or "Print" and "Parts"

In reply to by Jojo-Schmitz

But that's exactly how native windows apps work, and it works fine in applications that don't specify accelerators for all menu commands (Notepad++ is a good example). I don't believe any extra code was written for this, I assume it's built into standard Windows menus functionality - though annoyingly I can't find any MS documentation to back this up.

In reply to by Dylan Nicholson1

Might need to back that claim with some better proof as I just tried two other applications (iTunes and Visual Studio as it happens) and the auto-accelerator behaviour doesn't work there either! Interestingly most modern MS apps don't seem to use traditional menus any more either (Edge, Office apps etc., even Wordpad!).
So maybe it's just something Notepad++ does...if so...it's not a bad feature...

Actually Visual Studio does seem to have some sort of automatic accelerator behaviour - you can't see any accelerator keys underlined, but they do sort of work, however it seems random as to which menu option gets activated if there are multiple ones starting with the same letter, which isn't very useful.
But ultimately I have to confess I've never made use of this behaviour so I don't have a particular sense that it's important to add to Musescore - as long as there IS a simple way to assign keystrokes to commonly used commands, and perhaps plug-ins are the best solution for that...

In reply to by DanielR

If a menu option said "Paste (v)" in English it wouldn't bother me at all...(sorry I tried to underline the v but it doesn't seem to be supported here)
And as I pointed out, it's exactly what MS do at least for non-latin-language alphabets.
I'd say the reality is the software world is very much anglo-centric. There's virtually no programming language you could reasonably learn to code in without having some familiarity with English, and much of the documentation online providing critical info on how certain things work is often still only available in English (sure, you can often obtain versions that have been translated, but often not very reliably or accurately!)

In reply to by Dylan Nicholson1

That's not an accelerator but a shortcut though. Different thing entirely!
Accelerator is for example "File" > "Save (Ctrl+S)", that F and S, (here bold, but underlined in the menus), with Ctrl+S being the shortcut.
That F doesn't make any sense in German, hence there is us "Datei" > "Speichern (Strg+S)", i.e. a D instead of an F. Still an S for the 2nd part though (pure luck) and stil Ctrl+S being the shortcut (Ctrl is Strg on German keyboards)

In reply to by mirabilos

Yes, And make sure they are unique in there contexst. on Transifex the existing ones are now all commented so the translators see what this is about and in which context they belong to. But adding more of them needs more preparatory work too, that's why we're rather careful and conservative with them

BTW I realised the problem is worse than I thought. In native Windows apps, any menu item that isn't assigned an explicit accelerator can always be accessed by using the first letter of the menu name (if there are multiple menu items with that letter, you have to hit the letter until it selects the one you want, then you can hit 'enter').
But this doesn't work with MuseScore for some reason.
The same trick doesn't work in native Windows apps for dialog controls however, which is why presumably most native Window apps do generally in fact assign accelerators to all labels. And nor are they always unique, even in MS apps, e.g. the Outlook options dialog has "a" for "appearance" and "a" for "Always use these values".

In reply to by Dylan Nicholson1

I may have to retract this claim, it was based on a single application (Notepad++) and I haven't actually found any proof it is built-in to or common to other Windows apps. It doesn't work like this in Visual Studio 2019 anyway (which doesn't show accelerators for many of its menu commands, surprisingly - though it does have its own mechanism for assigning shortcut keys to any command).

Another thing to consider is that MuseScore is not just more than English, it's also more than just Windows. Whatever scheme is devised would also need to work on macOS and Linux, and feel natural on all three platforms - and be supported by the Qt and/or QML primitives we use for such things.

In principle, though, I think I get what you saying, Dylan. If the translation of, say, the word "Export" doesn't happen to contain the letter "E" (which is the current mnemonic in English at least), you could simply add "(E)" to the translation, so now it does contain the letter E, and it can thus be assigned as a mnemonic normally (e.g., by using "(&E)" in the translation, I guess).

Whether or not that is really something people using different languages or different OS would ever expect to see, I cannot say. But it does seem like potentially a nice design idea.

In reply to by Marc Sabatella

Honestly I don't know what the conventions are in Mac or X-windows based apps, though my impression from many Mac apps is that there's little effort put towards ensuring all commands are easily accessible via the keyboard.
But I have to admit when I started digging into a few other Windows apps last night I was pretty surprised how little consistency there was between apps, even official Microsoft ones (who seemed to have mostly abandoned traditional app menus recently).

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