Shortcuts using shift are not registered correctly.

• Dec 16, 2014 - 22:41
S4 - Minor

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.


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