summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qkeymapper.cpp
diff options
context:
space:
mode:
authorTor Arne Vestbø <tor.arne.vestbo@qt.io>2020-09-14 18:44:09 +0200
committerTor Arne Vestbø <tor.arne.vestbo@qt.io>2020-10-06 11:20:49 +0200
commit57d6f842eadcfe59337e223237ef024de3b0e433 (patch)
tree8dbdd5aea838064dda67974e5ab5713e37857951 /src/gui/kernel/qkeymapper.cpp
parent7aac974c78d488c1af39bb40feb5779c878dc4bf (diff)
Un-special-case macOS in handling of QKeyEvent::nativeScanCode()
In the porting from Qt 4 to Qt 5 an assumption was made in QKeyMapper that the underlying platform implementation needed the native scan code to be able to resolve the possible keymaps for an event. As a result, the macOS platform plugin started sending key events with a fake native scan code of 1, so that it would still be allowed to map key events. Which in turn led to the documentation of QKeyEvent::nativeScanCode() getting an exception for macOS. Let's clean up this by removing the original assumption, and leave it up to the platforms to decide what information from the key event is needed. QKeyMapperPrivate::possibleKeys() will still call extractKeyFromEvent as a fallback if the platform layer doesn't return any possible keys. Change-Id: I122a45bcec658c45ccc0b2c0671eb264d85d7be6 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Diffstat (limited to 'src/gui/kernel/qkeymapper.cpp')
-rw-r--r--src/gui/kernel/qkeymapper.cpp3
1 files changed, 0 insertions, 3 deletions
diff --git a/src/gui/kernel/qkeymapper.cpp b/src/gui/kernel/qkeymapper.cpp
index 89eacc944a..19b0e15279 100644
--- a/src/gui/kernel/qkeymapper.cpp
+++ b/src/gui/kernel/qkeymapper.cpp
@@ -83,9 +83,6 @@ static QList<int> extractKeyFromEvent(QKeyEvent *e)
QList<int> QKeyMapper::possibleKeys(QKeyEvent *e)
{
- if (!e->nativeScanCode())
- return extractKeyFromEvent(e);
-
return instance()->d_func()->possibleKeys(e);
}