QKeyEvent configuration
-
I have a question about QKeyEvents. I've inherited an embedded application which makes use of an eventFilter to look for input from the device's 4 directional keypad:
bool KeyPressEater::eventFilter(QObject *obj, QEvent *event) { if (event->type() == QEvent::KeyPress) { QKeyEvent *keyEvent = static_cast<QKeyEvent *>(event); switch ( keyEvent->key() ) { case Qt::Key_Up: emit UpKey(obj); break; case Qt::Key_Down: emit DownKey(obj); break; case Qt::Key_Left: emit LeftKey(obj); break; case Qt::Key_Right: emit RightKey(obj); break; case Qt::Key_Q: emit QKey(obj); break; default: break; } return true; } else return QObject::eventFilter(obj, event); }
Which all works well. I need to know how QT is configured to use the keypad - how does QT know that when a particular button is pressed that it is the the
Qt::Key_Left
orQt::Key_Right
key?Can anyone point me in the right direction to find out how this is configured?
Thanks!
-
I have a question about QKeyEvents. I've inherited an embedded application which makes use of an eventFilter to look for input from the device's 4 directional keypad:
bool KeyPressEater::eventFilter(QObject *obj, QEvent *event) { if (event->type() == QEvent::KeyPress) { QKeyEvent *keyEvent = static_cast<QKeyEvent *>(event); switch ( keyEvent->key() ) { case Qt::Key_Up: emit UpKey(obj); break; case Qt::Key_Down: emit DownKey(obj); break; case Qt::Key_Left: emit LeftKey(obj); break; case Qt::Key_Right: emit RightKey(obj); break; case Qt::Key_Q: emit QKey(obj); break; default: break; } return true; } else return QObject::eventFilter(obj, event); }
Which all works well. I need to know how QT is configured to use the keypad - how does QT know that when a particular button is pressed that it is the the
Qt::Key_Left
orQt::Key_Right
key?Can anyone point me in the right direction to find out how this is configured?
Thanks!
@radioraheem said:
Which all works well. I need to know how QT is configured to use the keypad - how does QT know that when a particular button is pressed that it is the the
Qt::Key_Left
orQt::Key_Right
key?Can anyone point me in the right direction to find out how this is configured?
Qt processes the platform events/messages in the Qt platform plugin and translates them to Qt events.
So probably your keypad's driver reacts on presses and it's driver forwards the events to the system which then forwards to Qt.Is that the information you requested?
-
@radioraheem said:
Which all works well. I need to know how QT is configured to use the keypad - how does QT know that when a particular button is pressed that it is the the
Qt::Key_Left
orQt::Key_Right
key?Can anyone point me in the right direction to find out how this is configured?
Qt processes the platform events/messages in the Qt platform plugin and translates them to Qt events.
So probably your keypad's driver reacts on presses and it's driver forwards the events to the system which then forwards to Qt.Is that the information you requested?
Thanks, @raven-worx - that is the type of info I was after.
Do you know where exactly the translation to QT events takes place? (You say "in the Qt platform plugin", but is there a config file or something for building this mapping, or something else?)
I'm working on an open-embedded based system and can see where the keypresses are translated by device tree's GPIO multiplexing but wanted to trace the signal paths through from there to QT...
Thnaks,
Iain
-
Thanks, @raven-worx - that is the type of info I was after.
Do you know where exactly the translation to QT events takes place? (You say "in the Qt platform plugin", but is there a config file or something for building this mapping, or something else?)
I'm working on an open-embedded based system and can see where the keypresses are translated by device tree's GPIO multiplexing but wanted to trace the signal paths through from there to QT...
Thnaks,
Iain
@radioraheem
no i can't tell you where to look exactly, would have to take a look myself.
But you can either way try to set a breakpoint in a keyevent handler in one of your widgets (only when the keyevent wasn't posted to the eventloop by the platform plugin) or you start digging in the source code of the platform plugin of your corresponding system. -
Thanks, @raven-worx - that is the type of info I was after.
Do you know where exactly the translation to QT events takes place? (You say "in the Qt platform plugin", but is there a config file or something for building this mapping, or something else?)
I'm working on an open-embedded based system and can see where the keypresses are translated by device tree's GPIO multiplexing but wanted to trace the signal paths through from there to QT...
Thnaks,
Iain
@radioraheem said:
Do you know where exactly the translation to QT events takes place? (You say "in the Qt platform plugin", but is there a config file or something for building this mapping, or something else?)
It's spread over multiple files and done in multiple stages. You could start by looking at the window system interface class.
Here:
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qwindowsysteminterface.cpp
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qwindowsysteminterface.h
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qwindowsysteminterface_p.hThere's also some code in the platform plugins:
http://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/inputKind regards.
-
@radioraheem said:
Do you know where exactly the translation to QT events takes place? (You say "in the Qt platform plugin", but is there a config file or something for building this mapping, or something else?)
It's spread over multiple files and done in multiple stages. You could start by looking at the window system interface class.
Here:
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qwindowsysteminterface.cpp
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qwindowsysteminterface.h
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qwindowsysteminterface_p.hThere's also some code in the platform plugins:
http://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/inputKind regards.
@kshegunov That's exactly what I was after - thanks!