How to make keyboard layout independent shortcuts

Robin Pedersen robinpeder at gmail.com
Wed Oct 22 09:06:13 BST 2008


In kate the default shortcut for code folding (Ctrl+Shift+'+') is  
impossible on US English and several other keyboard layouts, because the  
character '+' is assigned to Shift+'=' on these layouts [1][3].

I tried to get around this problem by using the shortcuts Ctrl+Shift+'['  
and Ctrl+Shift+']' for collapsing and expanding. This was not possible to  
configure in the Configure Shortcuts dialog, because Shift+'[' is actually  
'{', and the shortcut is stored as Ctrl+Shift+'{'. [2]

In an attempt to fix the shortcut dialog, I created a patch that caused it  
so store the shortcut as Ctrl+'{'. This worked fine for this shortcut in  
particular, but caused problems for other key combinations involving  
letters (e.g. Ctrl+Shift+'A').

I didn't realize this until now, and I don't know if this has been  
discussed here before, but this is actually quite a difficult problem. If  
we take a second, and forget about all Qt/KDE specific issues, what would  
be the correct behavior? Should we use Ctrl+Shift+'[' or Ctrl+'{' ? Should  
keyboard shortcuts be defined with respect to _keys_ or _characters_? In  
this case, '{' being the character, which happens to be mapped to the same  
key as '['.

On my particular keyboard layout, there's no difference between the two.  
However, I regularly switch between English and Norwegian layouts. With a  
Norwegian layout Ctrl+Shift+'[' and Ctrl+'{' are actually two different  
things, because '[' is AltGr+'8' and '{' as AltGr+'7'.

If shortcuts where defined with respect to _characters_ instead of _keys_,  
then it's guaranteed that the combination Ctrl+x is possible on any  
keyboard layout as long as:
1.1 - The character x is available
1.2 - The modifier key Ctrl never changes the character

I think (hope) point 1.2 is universally true. The Shift key, on the other  
hand _does_ change the character, as seen above ('=' becomes '+' and '['  
becomes '{'). That is exactly why we have these problems. The "bug" in Qt  
is that `QKeyEvent::key()` returns the _character_ and not the _key_,  
which I now think is not a bug, but how it must be to behave well with  
different keyboard layouts.

There are some exceptions where the Shift key doesn't change the  
character. One is all the regular letters, because the shortcuts seem to  
be case insensitive, which is why combinations like Ctrl+Shift+'A' does  
work. The function keys are also an exception.

Another issue is that we tend to use shortcuts that are "logical" (e.g.  
'+' and '-' for increase and decrease), to make them easy to remember. On  
a German layout, I think Shift+'+' is actually '*' and Shift+'-' is '_',  
which doesn't have the same meaning as '+' and '-'. Many such logical  
"errors" may arise when shortcuts are defined without having other layouts  
in mind.

My suggestion is to change the shortcuts dialog, and default shortcuts, so  
that all shortcuts are defined with respect to a _character_, and the only  
modifiers allowed are those that are guaranteed not to change the  
characters. This means:
2.1 - The modifier Shift is only allowed in combination with regular  
letters and function keys
2.2 - Ctrl and Alt are allowed with all characters
2.3 - The character is whatever is returned by `QKeyEvent::key()`

I created a second patch that allows Shift to be used as a modifier only  
with certain characters [2]. What do you think?

[1] https://bugs.kde.org/show_bug.cgi?id=124672 Bug 124672: impossible  
default shortcut for code folding
[2] https://bugs.kde.org/show_bug.cgi?id=173246 Bug 173246: Configure  
Shortcuts dialog doesn't work with some Ctrl+Shift combinations
[3] http://en.wikipedia.org/wiki/Keyboard_layout

-- 
Robin Pedersen



More information about the kde-core-devel mailing list