Finish QKeyMapper

[Dmitry A. Kuminov]

There are few things in QKeyMapper that remain to be done:

• Implement and test numpad functionality.
• Check that CapsLock and NumLock work as designed.
• Implement QKeyMapperPrivate::possibleKeys(). This somehow deals with shortcut maps.

[Dmitry A. Kuminov]

In r137, I provided a dummt QKeyMapperPrivate::possibleKeys() implementation just in case.

[Dmitry A. Kuminov]

A must for the GA.

[Dmitry A. Kuminov]

Added support for numpad keys and for some common multimedia keys recognized by eCS (volume, home, search, favorites) in r433.

[Dmitry A. Kuminov]

As far as I understand from the Win32/X11/Mac code, QKeyMapperPrivate::possibleKeys() is responsible for generating a list of possible key sequences resulting from the given key event. For example, given the key event Ctrl+Shift+Latin_A, it should emit a list that contains "A", Ctrl+"A" and Shift+"A", and if the request happens to be when the the Russian keyboard layout is active, then "A" should be replaced with "Ф" (this is a Cyrillic letter placed at the A key).

BTW, the lack of such support is the reason why Ctrl+<national> keyboard shortcuts don't work ATM. This should be doable in OS/2 using DosDevIOCtl() on the "KBD$" device and I will try to implement this since having non-working national shortcuts is not good.

[Dmitry A. Kuminov]

Qt is inconsistent, as usual. This time it showed up the fact that the logic processing of the hot keys differs depending on the active keyboard layout. What I mean makes sense for locales that use at least two keyboard layers (such as Russian, Hebrew or Arabic). The primary layout in this case is Latin and the secondary is National (where pressing the same keys produces National characters instead of the Latin ones).

What I found is that when the current layout of the Qt application is Latin, Qt will only see Ctrl+Q, Alt+Q, Q, etc. shortcuts when the Q key is pressed with the corresponding modifier. However, in National layout (where Q becomes Й for Russian) it will see both Ctrl+Й, Alt+Й, Й shortcuts *and* their Latin equivalents.

On practice, it means that if we have two buttons, one with the Ctrl+Q shortcut and the other one with the Ctrl+Й shortcut, then pressing Ctrl+Q (or Ctrl+Й which is actually the same physical key on the keyboard) in Latin mode will only activate the first button, while in National mode it will activate both. Inconsistency? Definitely. This corresponds to the Win32 version of Qt, I won't get surprised if X11 and Mac become even more differently, each in its own way...

[Dmitry A. Kuminov]

Just a few words about how it SHOULD HAVE been done to make it sane and consistent.

Alt+<letter> is traditionally used for mnemonic shortcuts in menus and button names where <letter> corresponds to the underlined letter in the menu item or button text. Since the text is always written in some certain language it makes sense to only react to Alt+<letter> presses when the pressed key actually corresponds to the given letter in the current keyboard layout. This means that in Russian, Alt+[Q/Й] should be treated as Alt+Й and only activate items that have Й underlined. And vice versa, if the layout is Latin, it should only activate items where Q is underlined. In short, the Alt+<letter> shortcuts are naturally language-dependent.

Regarding all other shortcuts, and especially the Ctrl+<letter> ones. While shortcuts of this type may carry some word in mind (e.g. Ctrl+C stands for Copy, Ctrl+O stands for Open) this connection is really loose -- the user normally doesn't see any textual hint when he presses Ctrl+C (as opposed to Alt+<letter> shortcuts where the user always sees the underlined letter in a context of a word). More over, if you change the language, this connection is simply broken at all: the same word in another language will more likely not even contain the given letter, not speaking about starting with it. Yes, one could change Ctrl-C to, say, Ctrl+K in the Russian translation of the product (Copy = Копировать) and some applications do *really* do that, but it should be considered as a crime because it makes it really painful for the user to have to remember different shortcuts depending on the layout. The explanation for this pain is simple: as I mentioned above, the user doesn't see any clear text when it presses Ctrl+<letter> shortcuts and therefore the brain (in the lack of textual information) remembers the shortcut by position of the key on the keyboard rather than by the letter. In other words, Ctrl+<letter> (and actually all other) shortcuts are naturally language-independent.

(BTW. Mozilla apps are still broken in this regard: I can't use Ctrl+C/V/X when the keybaord is in Russian and that simply kills my brain. The problem is there for all these years since the beginning and I hope I will finally find time to fix that in their code base and maybe even earn $500 if they still have a contest open on that issue :)

Note that one may say that Alt+<letter> should be also language independent so that the File menu may be called with the Alt+F press from non+Latin layouts (for example, in Russian, Alt+F becomes Alt+А) which will save people from the layout switch just for that purpose. Well, yes, maybe. The only potential problem there is that it makes it impossible to solve possible duplicate underlined letter conflicts if the UI contains both Latin and National words (e.g. Latin F and Cyrillic A) because the application writer cannot know which Latin letter will correspond to which National letter on the user's keyboard (I may switch to layout where Latin F will correspond to Ф). The problem is not really big as it's quite rare when the application contains UI elements in more than one language. (BTW2, I don't get why the underlined letters are still defined by the application writer nowadays: the only correct solution is to assign them automatically which would avoid any conflicts and related problems).

[Dmitry A. Kuminov]

Implemented the described approach including the note (so that Alt+<letter> are language-independent so far) in r434.

I must say that it works pretty cool (at least in Russian and in the examples like demos/textedit that I tried), I don't really have to care about the keyboard layout when doing shortcuts anymore. Let's see how it will work on other systems with other applications. Note that it should work similarly for any other bidirectional layout

Please feel free to open another ticket if you find any problems.

PS. I didn't actually use the direct KBD$ access as there is more clean Kbd API for exactly this.