Keyboard shortcuts not working or displaying properly; users should not select keyboard layout

• Aug 4, 2021 - 01:20

OS: Windows 10 (10.0), Arch.: x86_64
MuseScore version (64-bit): 3.6.2.548021803, revision: 3224f34

INTRODUCTION
MuseScore is one of the rare software that asks the user for keyboard layout at startup. Most software does not ask this, since this information is irrelevant. Software should simply read the key names and VK codes instead.

PROBLEM
The default layout is based on the regional settings and not the active keyboard layout. Despite switching keyboard layout, to for example Spanish or German T1, the keyboard shortcut hints in menus are still based on the US layout. The list of layouts is much smaller than what Windows offers, and it also puts a limitations on users with custom keyboard layouts. MuseScore is also reading the literal characters, and not the VK codes. So when it asks me to press "<", it asks me to press the literal key combination that would yield <. Furthermore, "<" is not a valid key name on a US keyboard, it should say "Shift+," instead. Since not all layouts have < >, therefore some users won't be able to use these shortcuts.

EXPECTATION
Like most software, MuseScore should not ask the user for their keyboard layout in the first place. MuseScore should display the actual key names in the shortcuts based on the active layout, display the actual full shortcuts and not ignore "Shift+", and read VK codes and not literal characters. So the shortcut "<" should say "Shift+," on a US layout and "Shift+ქ" on a Georgian layout.

SOLUTION
MuseScore should only use the VK codes for all keyboard shortcuts. It currently does this for the letters A-Z, so even switching to a Russian layout still lets you type the equivalent of A-Z and make it work. But for the shortcuts of < > and { }, here it incorrectly expects literal characters. These should be replaced with VK_OEM_COMMA, VK_OEM_PERIOD, VK_OEM_4, VK_OEM_6 respectively. So layouts that lacks < > {} (such as the Russian layout) will still work, since they still have the same VK codes regardless of what symbols they output.

MuseScore should also display proper shortcut codes based on the key names and modifier keys. If it requests VK_OEM_4 to be pressed for a shortcut, it should read what the unshifted symbol is for VK_OEM_4, and the display Ctrl+ Shift+ Alt+ in front of it as needed. For < > { } it should instead display Shift+ followed by the corresponding unshifted key on the active keyboard layout. On the US layout, that would be Shift+, Shift+. Shift+[ Shift+] respectively. And when the user have the German keyboard layout active, the shortcuts should instead display Shift+, Shift+. Shift+ß Shift+´

Comments

• Aug 4, 2021 - 10:15

As an average keyboard user, I'm interested...

You wrote:
"So layouts that lacks < > {} (such as the Russian layout) will still work, since they still have the same VK codes regardless of what symbols they output."

Are you saying, for instance, that for a person with the Russian keyboard layout, MuseScore shortcuts like { (decrease stretch) and } (increase stretch) do not work "out of the box", but will only work if the shortcut keystrokes are redefined in Preferences -> Shortcuts by the user?
... and that by using VK codes this would not be necessary, and the shortcuts would work right "out of the box"?

https://docs.microsoft.com/en-us/windows/win32/inputdev/virtual-key-cod…

Reply

• Aug 4, 2021 - 14:18

> "Are you saying, for instance, that for a person with the Russian keyboard layout, MuseScore shortcuts like { (decrease stretch) and } (increase stretch) do not work "out of the box", but will only work if the shortcut keystrokes are redefined in Preferences -> Shortcuts by the user?"

Yes. After switching to the Russian layout, yes. None of the keys will trigger the increase stretch. But going to settings, I can replace the increase stretch shortcut to Б and now it works with the Russian keyboard. But after replacing it, now I can't trigger it on my standard keyboard.

This kinda proves that MuseScore reads literal characters instead of VK codes.

> .. and that by using VK codes this would not be necessary, and the shortcuts would work right "out of the box"?

Exactly. Increase stretch should not be set to the literal character }, but instead it should be set to the VK code combination of VK_SHIFT+VK_OEM_6, since this is the required combination on US and UK layouts. It should also display the unshifted symbol for VK_OEM_6. This is how software works by standard. This will make it work out of the box for a Russian user, and the shortcut prompt would even say Shift+ъ.

(By standard, Microsoft ignores the shifted position even if it's an uppercase letter. I personally think Shift+Ъ would look nicer, since it would say Shift+A, but that's apparently not what Microsoft uses)

Example from Microsoft Visual Studio:
US keyboard | UK keyboard | Russian keyboard
VisualStudio.png
Terminal is set to VK_CONTROL+VK_OEM_3, and OEM3 is the `~ key on the US layout, the '@ key on the UK layout and the ёЁ key on the Russian layout. Visual Studio shows this correctly and works with any layout.

Reply

• Aug 4, 2021 - 14:25

After some more testing, I'd also like to report that, the shortcuts for the letters A-Z actually do use the VK codes VK_A through VK_Z, so they still function properly on the Russian layout. But only if you set a Latin letter as the shortcut in the shortcut menu. So if the Russian user decides to set Instruments, which currently is on key Ш (Cyrillic sh, VK_I) to key И (Cyrillic i, VK_B, for the Russian word "инструмент"), the shortcut menu will now say И. But, since if the users press any key from VK_A through VK_Z, it will trigger the VK code instead of the literal character, so the shortcut set to И will not trigger since a literal И is never sent. The dropdown menu will still say to press И, but it will not trigger. The Russian user has to switch to a second layout, press B, then it will work both on the Russian and the other Latin keyboard.

But if I set the shortcut to key Ё (Cyrillic yo, VK_OEM_3), then it will work again, since VK_OEM_3 isn't a letter, therefore it will send the literal Ё character instead.

All this complication will be avoided by simply using VK codes throughout.

Reply

• Aug 7, 2021 - 22:13

As a Belgian Azerty dot user with ISO-dead-keys and mixed regional settings I respectfully and completely disagree.
You're also assuming that MuseScore has access to the VK information (which it almost certainly has on Windows, but not as certain on other operating systems, where every key press would result in VK_0).

Reply

• Aug 8, 2021 - 16:14

I don't understand exactly what the issue is. Other operating systems don't have similar systems to determine keys independent of the layout? Some quick searching and it looks like the equivalent for Mac are rbKey codes. Of course a universal standard would improve things.

You not using a US/UK keyboard would be a good reason to why you want MuseScore to use VK codes and not literal characters.

Plus it appears as if MuseScore is using VK codes already. A–Z seems to properly use the VK codes, while non-A–Z does not use VK code and that's where it fails. It should use VK codes for all keys.

Reply

• Aug 8, 2021 - 22:05

If you can figure out how to get decent key information in the Qt version used by MuseScore for cross-platform abstraction (or a different, proven good library that can interact with Qt) then be my guest.

But one of the things that MuseScore does after I tell it I have an Azerty keyboard (for which autodetection blatantly fails) it does serve me different default shortcuts than those from the US-QWERTY versions.

Reply

• Aug 9, 2021 - 03:58

MuseScore absolutely should not use the VK_* scancodes for shortcuts!

For example, { and } deal with layout stretch. On a US keyboard, these are on keys [LFSH]+[AD11] and [LFSH]+[AD12], on a German keyboard, on [RALT]+[AE07] and [RALT]+[AE10], on a Neo 2 keyboard, on [CAPS]+[AC03] or [BKSL]+[AC03] and [CAPS]+[AC04] or [BKSL]+[AC04], respectively, etc.

The keyboard shortcuts are mnemonic, not based on the position. Curly braces, as defined by the current keyboard layout, mean change layout stretch. On nōn-AZERTY layouts, shifted nōn-numpad numbers mean something (on AZERTY layouts, the numbers are already shifted in their base state, so they need a different set of standard shortcuts). Etc. pp.

Even note input! ‘a’, for example, is on [AC01] on US and German keyboards, on [AD01] on French keyboards. You don’t expect a frenchie to type Q when they want to input the note A, right?

Reply

• Aug 9, 2021 - 05:24

@ Liggliluff
Hmm...
Are you using one keyboard and changing the layout of that keyboard and so want (shortcut) keystrokes to remain the same across different layouts (with no literal key interpretations, other than by using the original layout)?

So when you wrote:
"So the shortcut "<" should say "Shift+," on a US layout and "Shift+ქ" on a Georgian layout."

Do you mean that a US keyboard (modified via some app) with a Georgian layout will produce a "ქ" when a "," is pressed on it?
And so mirabilos' concern:
"You don’t expect a frenchie to type Q when they want to input the note A, right?"
...arises because of the different literal meaning of a key vs the key's VK code?
QWERTY vs AZERTY -- "Q" and "A" having the same keycode on each layout, but a different literal mapping, so "Q" could mean "A".

Reply

• Aug 9, 2021 - 18:17

mirabilos is wrong though.

When the software requests you to press VK_A, it will be A on every layout that has the VK codes defined based on the layout. On AZERTY, the letter A is VK_A not VK_Q as mirabilos incorrectly states.

Plus as far as I can tell, MuseScore already uses VK_A through VK_Z for the letters. So when you press key A on AZERTY, you are sending VK_A that MuseScore detects and treats as an A input. Since the Russian layout is using the US VK code layout, that means that Ф (ef) gives VK_A, so a Russian would press Ф (ef) instead of A (a) to send VK_A ... and in MuseScore, a Russian has to press Ф and not A for A.

Reply

• Aug 9, 2021 - 23:18

VK codes are a weird mix between scancode and keycode, but they have a property that makes them counted towards scancodes: they are unshifted.

The unshifted/shifted variants of things mapped to the same key differ across keyboard layouts, which the VK_* don’t map.

(While I haven’t seen one, it’s possible to have a keyboard layout where ‘a’ and ‘A’ are on different keys. On my Meta-based keyboard layout, the upper-case Ü is the unshifted version, the lower-case ü the shifted version, by necessity, so this kind of diverging also exists.)

But ultimately, MuseScore can only use what the Qt library offers, so there’s that. Qt used to be really broken over VNC for a while, but that got fixed eventually, for example, so Qt only offers a high-level interface with no promise of how it’s realised below.

The shortcuts in the menu should just match what’s configured, that’s all.

Reply

• Aug 14, 2021 - 15:50

I'm no expert, and I have no idea what "VK" is, but I do think an important point is missed here. The reason for checking keyboard layout is not related to key codes as far as I know, but to allow for different shortcuts to be used that are more optimized to different layouts. As one practical example, Shift+5 is different from 5 on most keyboard, but not AZERTY. So in principle, the AZERTY layout would assign shortcuts that don't rely on these being different. Another potential example: Q & W are adjacent on QWERTY keyboards, making them convenient to use for half/double duration. Not necessary so on non-QWERTY layouts (although they do happen to be in similar proximity on AZERTY).

So, regardless of what the right or wrong way is to get key codes, or whether the specific version of Qt we use to process this supports the preferred method, it still seems relevant to me to know the layout and to use the correspondingly-optimized shortcut set.

Reply

• Aug 15, 2021 - 07:09

VK codes is simply which keys represents letters A-Z, digits 0-9, the keys for comma, period, plus, minus, and then 8 "extra" keys and the "extra 102nd" key.

If you read VK_5 for example, it will be the key representing digit 5 on every layout. It doesn't matter what the unshifted or shifted symbols are. If the software requests the user to press Shift+5, the user presses Shift+5 on any layout, including AZERTY layouts.

You have a point about using keys like QW if you want them to be related to each other. QW would be bad for a Dvorak layout for example. But since the VK codes are used for the letters (so they work on non-Latin keyboards), and otherwise the literal symbol output are used; this means that by default, the symbols are inefficiently spread out anyway and not more optimised.

But selecting keyboard layout doesn't seem to work anyway, and the list of layouts is too limited. No Swedish layout? It's still awkward that MuseScore is so far the only software I have that has asked for layout. Kind of shows how bad it handles layouts, since all other software just works fine.

Reading other replies, it appears as Qt is the biggest issue here, being too limited. But a more proper solution might be to use scan codes instead. Use the scan codes for QW, [] and the other pairs; through this, you don't need to ask for which layout the user has. Is the person using the Svorak layout that is rare? No problem, just press ÅÄ instead of QW, and ,¨ instead of []. And instead of CDEFGAB for key input, why not make it ASDFGH (which then becomes AOEUID on both Svorak and Dvorak). – Then for the symbol to output, which is a little more advanced; get the unshifted, and shifted symbols; if one is a digit, use that; if not, then if the shifted is the uppercase form of the unshifted, use that; if not, use the unshifted form. So don't write "{" but "Shift+[". This ensures digits are used on QWERTY and AZERTY, and that the uppercase letter is used for A-Z as well as German ÄÖÜ, and not the uppercase for French ù since the shifted form is %.

Reply

• Aug 15, 2021 - 10:42

MuseScore keyboard management is far from perfect and could certainly be improved.
But I can't see how your last post suggestion to change shortcuts for pitches from c d e f g a b to something else would be an improvement in any matter. C d e f g a b are by far the most logical and easier shortcuts to remember from the whole system.

Reply

• Aug 15, 2021 - 15:40

Let me be simpler and more direct:

Does VK somehow contain code that allows a French AZERTY user to type "5" to do one thing, and "Shift+5" to do something else? How does it accomplish this? What physical keys would a French user press to execute the "5" command, and then what different physical keys would that same user process to execute the "Shift+5" command?

Reply

• Aug 15, 2021 - 17:37

As an AZERTY keyboard user, I would add this:
-To get the character 5 (e.g. in any text editor) I need to push on Shift+[the key with 5] (or be lucky enough to have a numpad but they disappear even on 15.6" laptops nowadays)
-Thankfully MuseScore is smart enough and doesn't require us to enter the character 5 for quarter notes, it happily accepts the character of "the 5 Key" without the shift.
-That being said, I can't imagine any way for MuseScore to propose me a shortcut shift+5 for another action without being horribly ambiguous... Shift+5 "is" 5 from a AZERTY user point of view. So even if a technical solution would be possible to offert shortcut 5 and another distinct shortcut shift+5 that would be a terrible design idea

Reply

• Aug 16, 2021 - 08:08

It appears as if MuseScore does use VK codes for digits too, like letters. It just fails to do it to non alphanumerical keys.

In standard Windows, when it tells you to press "5" as the shortcut; you simply press the key that has the 5 on it, without pressing Shift; regardless if you use QWERTY, AZERTY, or that Dvorak with re-arranged numbers. If the shortcut needs you to press shift, it will instead tell you to press "Shift+5". You then hold Shift and press the key that has the 5 on it; again regardless if you use QWERTY, AZERTY or whatever.

Where MuseScore fails is that it expect you to press the literal characters for { } which it shouldn't do. This results in potential conflicts and makes it sometimes awkward to use in certain layouts. MuseScore has tried to alleviate this by asking for the layout (but their layout list is so short); but this is trying to fix an issue that shouldn't be there to begin with. Using VK codes, as per standard, would prevent any of these issues, and they don't have to ask for your layout.

Reply

• Aug 16, 2021 - 06:27

VK code only refers to the key itself, not any modifiers. The key that contains digit 5 will be VK_5. It doesn't matter what modifiers you need to press to get the actual digit. So when the software tells the user that a shortcut is by pressing key 5, you simply press the key that contains the digit 5 without any modifiers. If the software says Shift+5, you then press Shift and the key with digit 5.

This is how Windows (and likely other operating systems) are designed by default. This is how Microsoft and other software developers make their software. This is how it's intended to be made. When software breaks these rules, like MuseScore and Adobe; it makes the software more annoying to use for those that don't have a US/UK keyboard.

On Windows, a key will only be referred to as A–Z, 0–9 or the unshifted symbol. So as a Swedish user, I will only see the symbols: A–Z 0–9 å ä ö § + ´¨ ' < , . - and when any other symbol shows up, the software isn't following this standard.

Reply

• Aug 16, 2021 - 06:45

MuseScore would still need to know the keyboard layout because the 5 is already shifted in French so supporting an AZERTY keyboard needs a different set of shortcuts (and probably some hard liquor).

Now stop bothering people with Microsoft-specific things that don’t apply to the Macintosh, GNU/Linux, the BSDs or anything else, nor portable software including software written in Qt.

The only thing I found to take away from this discussion is that (apparently — I haven’t noticed it yet but haven’t looked either) the shortcuts shown in the menu don’t correspond to the actual shortcuts configured. If this is so, it’s definitely a bug, and that one should be fixed.

Reply

• Aug 16, 2021 - 08:02

You don't seem to understand what VK codes are. VK codes aren't shifted. VK_5 on a QWERTY and AZERTY are never shifted. To print a literal digit 5 on an AZERTY you need to press Shift+VK_5, but to use the shortcut 5 on an AZERTY you press VK_5.

AZERTY does not need a different set of shortcuts; that is why you should use VK codes.

I haven't used Macintosh myself; but I have a strong feeling they have a very similar system. Because using VK codes is far the superior option, since it ensures that shortcuts always works regardless of what keyboard you're using, and it's less work for developer since they don't have to deal with different layouts. Since Apple produces higher quality user-friendly product and software, they don't want their software to not function properly just because you're using a different layout, and they wouldn't let Microsoft have an upper hand here.

If I recall correctly, Mac even has an option for Dvoark to use QWERTY shortcuts; and that sounds like it's a Dvorak layout but instead of assigning the VK codes to the new key arrangement, it has the VK codes like the regular QWERTY layout instead. So Q on a Dvorak would normally be VK_Q, but for the QWERTY shortcut mode it will instead "incorrectly" use VK_X to preserve the positions of shortcuts.

The shortcuts in menus shows the literal character to press in MuseScore, which breaks the standard of Windows. I can't tell if that's actually how it's done on Mac. Windows would say "Shift+," but does Mac say "⇧," or would it instead say "<" on a US layout? Best I can find is this one: https://cdn.statically.io/img/i.pinimg.com/originals/a8/ea/ab/a8eaabc25… which is using literal characters for [ ] and { }, instead of saying ⇧[ ⇧] for the latter pair. But it isn't official so I can't say if this is actually how it's done on Mac. But if it's true, MuseScore follows the Mac standard in that case, which would be wrong on Windows.

Reply

• Aug 16, 2021 - 08:12

As far as I can tell that VK codes stuff is Microsoft specific. And as such not available on Mac or Linux, and because of that not feasible to use in a multi-platform program like MuseScore.
Certainly not available in Qt, the library MuseScore uses for all the UI and to abstract the various operating systems

Reply

• Aug 16, 2021 - 17:33

> > "But Qt is using VK codes for letters and numbers"
> Is it?

No it isn't, you are right. Testing with AZERTY, it does not recognise the digits unless I press Shift. Only letters are using VK codes. I have tested this by running a custom Arabic layout, which MuseScore/Qt should have no idea how it's defined; and despite moving the VK_I (instrument) around, it still picks up the right key.

So digits and other special symbols are read as literal characters, and you must press the exact combination to get it. If you lack that symbol, you can't use it. But letters A–Z are using VK_A–VK_Z and will work regardless of what alphabet or script you're using (works with Cyrillic, Arabic). MuseScore/Qt isn't doing any conversion from these scripts either, because trying the default Russian layout with letter Ш on VK_I and Serbian with letter И on VK_I, it handled both correctly. If it did converting, it wouldn't be able to tell what VK code Ш was defined as. MuseScore/Qt must be using VK codes specifically for the letters.

But when you define a custom shortcut, your input will be treated as literal. So if you don't have a Latin layout, your input will be a Cyrillic or Arabic letter, and the shortcut won't work anymore. What it should do is recognise what VK code the key has and store that instead.

Reply

• Aug 16, 2021 - 10:21

No it isn't.
It simulates that by knowing which character does generate the "5" key without shift (e.g. "(" on my Belgian AZERTY keyboard). That's (a.o.) why it needs to know your keyboard layout.
And while I follow you on VK keys for digits & letters, I disagree for characters like {
Because { is in fact on the 9 key (for my keyboard), so VK_9 is equal to VK_{ that would make a conflict.
And in fact ... VK_{ just doesn't exist https://docs.microsoft.com/en-us/windows/win32/inputdev/virtual-key-cod…

Reply

• Aug 16, 2021 - 21:35

My keyboard has no AltGr key. It has a Mode_switch key on the left Alt key though, which works similar. (This is “fun” with shortcuts. My left Windows key produces Alt. If the software uses the equivalent of VK code, shortcuts with Alt in them simply don’t work, if it doesn’t, they work, I just have to press the key that produces Alt on my keyboard.)

Reply

• Aug 16, 2021 - 17:17

> I disagree for characters like {
Because { is in fact on the 9 key (for my keyboard), so VK_9 is equal to VK_{ that would make a conflict.

VK_{ does not exist. You're talking about literal symbols, which MuseScore is currently using for {, and I argue for VK codes which does not use the literal character {. Every key has a unique VK code, and one key does not have two or more VK codes. The actual VK code for what is { on the US/UK layout is VK_OEM_4, which is a different key on your keyboard. So when a software would expect a US/UK user to press the symbol {, it would define that shortcut as VK_SHIFT + VK_OEM_4, which then is converted to being displayed as Shift+[ on when using the US/UK layout. But on the French layout it's Shift+) and on the Slovak layout it's Shift+ú.

Reply

• Aug 16, 2021 - 17:35

> Which would mean those keyboard shortcuts (they come in a pair, increase and decrease, hence both curly braces) lose their meaning for the end user.

That is an issue that is beyond the scope of MuseScore/Qt. It would be nice if VK_OEM_4 and VK_OEM_6 was placed in such a way that they as often as possible represented some form of "left" and "right" on every layout; but that's not on MuseScore/Qt to deal with.

Reply

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