Shortcuts using shift are not registered correctly.
When I hit Ctrl-Shift-. on my keyboard (I'm on Dvorak) in 4d2317e it is being registered as Ctrl-Shift->. Shift-. produces > on my keyboard. This shortcut is not recognized in the program when I try to use it.
Likewes, when I register > as a shortcut to a command and I use Ctrl-Shift-. the command is initiated while it shouldn't.
I'm on Ubuntu.
Comments
Are you sure it's *all* shortcuts using shift that are a problem? It's a known issue that these two specific key combinations conflict on some keyboards - see #34306: Default keyboard shortcuts for staccato and decrescendo cause neither to work. If you are seeing something more than that, could you please elaborate? Otherwise we can close this as a duplicate.
Not all, but quite a few. Everything using regular letters seems to be OK. Everything that means something different when using shift seems to be having problems getting registered correctly. What seems to be happening is that instead of registering the pressed Ctrl-Shift-[key] it registers it as Ctrl-Shift-[shifted version of key]. This is OK with letters, but not with other keys since they do not at all correspond.
The problem is in the way qKeyEvent interprets a keypress and how we translate that to something that qAction with qKeySequence understands. An example:
when pressing shift-5 this gets registered as shift-%
If you want a corresponding qKeySequence you need only the "%"-part not the modifier shift. We could solve this somewhat with code like:
if((k & Qt::ShiftModifier) && ((e->key() < 0x41) || (e->key() > 0x5a)))
{
qDebug() << k;
k -= Qt::ShiftModifier;
qDebug() << k;
}
inserted before https://github.com/musescore/MuseScore/blob/master/mscore/shortcutcaptu… but the problem is simply: we don't know what the layout is of the keyboard. We want this substraction only to happen when shift actually modifies the key in the keyboard-layout the user is using. I'm afraid the only real solution is having a different dialog where the user chooses the key + the modifiers he or she wants to use.
the first if should also add || (e->key() >= 0x01000000)
Considering http://qt-project.org/doc/qt-4.8/qt.html#Key-enum this should more or less nail it.
The problem remains though that we have no way of finding out whether all modifiers are needed or not. This depends on the keyboard layout. There are two correct ways out of this problem:
1. We don't use the shortcuts on actions and write our own keyhandling routine which would call the action instead of letting qt do it for us. This way we could capture the qkeyevent and don't bother about this problem. Shortcuts would always work this way.
2. We provide an interface to the user to define the shortcut in terms of a key and modifiers.
The simple solution which would probably work in most circumstances is the fix I propose above.
Fixed in 2040c68275
Automatically closed -- issue fixed for 2 weeks with no activity.