[Interest] Qt/Mac low-level hacking: key mapping and NSMenuFunctionKey

[René J.V. Bertin]

On Sunday January 29 2017 15:28:29 René J.V. Bertin wrote:

> In short, I must manage to get qt_mac_get_key() to fall through to its final loop where it checks "if they belong to key codes in private unicode range". Any suggestions how I can get there without patching qcocoakeymapper.mm ? Has anyone ever been able to test this particular case/configuration with a keyboard that does have a Menu key, or with a system keymap that generates actual NSMenuFunctionKey strokes (or a properly configured ~/Library/KeyBindings/DefaultKeyBinding.dict)?

The question boils down to

- how and where does QChar(0x01000030) (Key_F1) map to 0xf704 (0xf704 is undoubtedly a Mac-specific Unicode value for F1)
- why do QCocoaKeyMapper::updateKeyMap() and qt_mac_get_key() get a QChar as argument if the full range of QKeyEvent::key() cannot be mapped to a 16 bit value?

It seems that QKeyEvent::key() is already a Qt::Key_* value from enum Key. That enum contains a range of entries that correspond to special keys that are not subject to keyboard mapping (in the sense of En or Fr or De or ...)
Given that, why doesn't qt_mac_get_key() get the event as an additional optional parameter, which could be used for something like

    if (event) {
        int rawKey = event->key();
        // check if the event's key "code" can be a 16 bit Unicode QChar or if not
        // if it's in the appropriate range corresponding to extended Qt::Key_* codes
        if (rawKey > 0xffff && rawKey >= Qt::Key_Escape && rawKey < Qt::Key_unknown) {
            return rawKey;
        }
    }

Little cost for "normal" keystrokes, but it allows to skip the full range of tests for those special keys, tests which could succeed inappropriately.

R.