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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
