Shortcut keys with multiple keybord layouts

Simon Kågedal <simon at helgo dot net>

Written: 2009-02-02
Latest update: 2009-02-03

The problem

This document aims to describe the current inconsistency in behavior of access keys and shortcut keys on the X desktop. The basic problem is that users of non-latin keyboard layouts need to be able to use shortcuts and access keys composed of a modifier and a latin character, even when their keymap does not have latin characters. Various toolkits and individual applications have solved this problem in slightly different ways, leading to inconsistent behavior.

Definitions

Keycodes: "Physical keys", or scan codes – for example, one keycode represents the left-most key of the first row.
Symbols: "Logical keys", such as "Escape" or "Q".
Keyboard layout: Mapping of keycodes to symbols – see XKB Configuration Guide.
Key group: The X keyboard extension allows for the keyboard to switch between different character groups. This is usually done for making a keyboard behave like a keyboard of a different language. In this context, the set of characters that are generated by the keyboard are called a group, and a keyboard can switch to a different group at any time.(Wikipedia)
Access key: Gives access to all controls in the user interface without using a mouse by pressing Alt + <underlined key>.
Shortcut key: Used to quickly reach often-used commands, e. g., Ctrl+S for save.

Use cases

The following use cases are designed to illustrate the various conflicting needs.

Basem lives in Algeria. His keyboard has both Arabic and French AZERTY layout printed on them, and he therefore has two key groups configured: Arabic and French. When switching to the Arabic group, where he can't directly type latin letters, he expects shortcuts like Ctrl+X to work just like they do under AZERTY.
Adrienne lives in France and has a French AZERTY keyboard. She works as a programmer, but finds it difficult to program with a French layout because common programming language characters such as [ and { are difficult to access. Therefore, she has taught herself to also use a US QWERTY layout, and thus has two key groups configured. She expects the key that has an "A" printed on it (just right of the Tab key) to emit an A when in French mode, and Q when in US mode; thus, when Control is held, she expects this key to emit "Ctrl+A" ("select all text") when in French mode and "Ctrl+Q" ("quit") when in US mode.
Jennifer is Basem's wife, an American woman who has been typing QWERTY for all her life, and is now living in Algeria. She's slowly learning Arabic, and uses an Algerian Arabic/French keyboard, but when she writes e-mails to people back home, she prefers to use a QWERTY layout since it's "in her fingers".
Steve is an American who uses Dvorak alternatively with QWERTY, since he finds it makes him more effective in some situations. Unlike Adrienne, he wants Ctrl+<any key> to always work like it's a QWERTY keyboard.

Situation today

I tested this on a Ubuntu 8.10 system running GNOME. GNOME (GTK+) was tested using gedit. KDE (Qt) was tested using kate. OpenOffice (Writer) and Mozilla Firefox uses GTK+, but have their own system for handling keyboard input. I also tested Windows for comparison.

Right now I have only tested shortcuts, but I guess access keys work similarly.

In Microsoft Windows XP, this behavior seems to be fixed for each layout. I was not able to test the Algerian case, those key mappings were not available in the version I was able to test this on. However, I tried with a Greek layout, and it seemed to always work like a QWERTY keyboard when holding down Ctrl, even if the two key groups I had configured where Greek and French AZERTY. I'm guessing there's an "Algerian Arabic" (or Moroccian, Tunisian...) with AZERTY-shortcuts.
In GTK+, when pressing a shortcut, all groups are searched in a weird way. For Adrienne, pressing either "Ctrl-A" or "Ctrl-Q" will select all text, whether she has selected the French or the US group. A patch for GTK+ is in Subversion which fixes this problem by always using the current key group if it can. Problems still remain for Jennifer when in Arabic mode, the odd behavior with both Ctrl-A and Ctrl-Q selecting all text is still there.
In Qt, when pressing a shortcut, the first key group is always used. This means that Basem needs to have the France keymap first, Arabic keymap second. If Arabic is first, no shortcuts will work in either key group. This makes the KDE apps perfect for Steve, but bad for Adrienne and Jennifer.
OpenOffice seems to try first the active key group, and then the first key group. Basem's correct configuration will be France first, then Arabic; but unlike the KDE case, if his configuration has Arabic first and then France, the shortcuts will work when the France key group is active.
Firefox seems to try first the active key group, and then the other available key groups in order.

Person	Windows	GTK+	GTK+ 2.15.3	KDE	Firefox	OpenOffice
Basem	OK?	OK	OK	OK if France is first	OK	OK if France is first
Adrienne	OK	Fail	OK	Fail	OK	OK
Jennifer	OK?	Fail	Fail	Fail	OK if France is first	OK if France is first
Steven	Fail	Fail	Fail	OK if QWERTY first	Fail	Fail

Proposed standard