QWidgets stop responding to simulated mouse events
-
I've seen similar behavior with a driver that failed to send touch release events. One of the widgets (or rather Item, using quick not widgets) was consuming all input while waiting for the release that never arrived. We diagnosed it by installing an event filter on the QGuiApplication instance.
-
@SGaist Tried this and the behavior is the same.
-
@SGaist Tried this and the behavior is the same.
@packetpirate said in QWidgets stop responding to simulated mouse events:
@SGaist Tried this and the behavior is the same.
Correction. I had only commented out where we set it to false. Setting it explicitly to true results in the dialog never coming back and the process hanging there.
-
@jeremy_k Could you give more details? What did the event filter do?
@packetpirate said in QWidgets stop responding to simulated mouse events:
@jeremy_k Could you give more details? What did the event filter do?
I find event filters to be a useful debugging aid, to see what events are delivered, to which recipient, and when.
struct Object : public QObject { bool eventFilter(QObject *watched, QEvent *event) override { qDebug() << watched << event->type(); return QObject::eventFilter(watched, event); } }; int main() { QApplication app; Object filter; app.installEventFilter(&filter); return app.exec(); } -
@packetpirate said in QWidgets stop responding to simulated mouse events:
@jeremy_k Could you give more details? What did the event filter do?
I find event filters to be a useful debugging aid, to see what events are delivered, to which recipient, and when.
struct Object : public QObject { bool eventFilter(QObject *watched, QEvent *event) override { qDebug() << watched << event->type(); return QObject::eventFilter(watched, event); } }; int main() { QApplication app; Object filter; app.installEventFilter(&filter); return app.exec(); }@jeremy_k Ah, I see. This won't really help me though since the events aren't delivered to the dialog. They're delivered straight to the widget. When I synthesize the mouse events from the touchscreen data, I get the coordinates and use the QApplication::widgetAt() method to identify the widget underneath the touch point, and then call QApplication::postEvent() to send the mouse event directly to that widget. The widgets are part of the dialog and defined in the UI file, so they don't have their own class where I can define an eventFilter for them.
-
@jeremy_k Ah, I see. This won't really help me though since the events aren't delivered to the dialog. They're delivered straight to the widget. When I synthesize the mouse events from the touchscreen data, I get the coordinates and use the QApplication::widgetAt() method to identify the widget underneath the touch point, and then call QApplication::postEvent() to send the mouse event directly to that widget. The widgets are part of the dialog and defined in the UI file, so they don't have their own class where I can define an eventFilter for them.
@packetpirate said in QWidgets stop responding to simulated mouse events:
@jeremy_k Ah, I see. This won't really help me though since the events aren't delivered to the dialog.
That's why the example installs the event filter on the QApplication. This allows it to see events delivered to all QObject instances.
-
@packetpirate said in QWidgets stop responding to simulated mouse events:
@jeremy_k Ah, I see. This won't really help me though since the events aren't delivered to the dialog.
That's why the example installs the event filter on the QApplication. This allows it to see events delivered to all QObject instances.
@jeremy_k Alright, so this did finally help me get some new information, though I'm not sure what it means yet. I added debug messages both where I created the mouse events for press and release, and installed an event filter that does what you showed, but only prints a debug message if it's a mouse press or release event.
The messages show properly on both sides no matter what, so the buttons ARE receiving the mouse events. But I also added debug messages where I manually set focus on certain types of widgets, such as QLineEdit and QComboBox which are present on the login form. I have a message before and after calling setFocus() on them to verify the focus gets set.
Before the failed login, the focus is properly set when I touch the password field. But after a failed login, when I touch the password field, my debug messages indicate even after manually setting focus on the widget, it doesn't have focus. So even though the on-screen keyboard buttons are receiving the events, there's nowhere to output the text I'm typing.
But there's one specific QComboBox on the login form that after I press it and select something, suddenly pressing the password field will properly set the focus again and allow me to type.
What's going on here?
-
After playing around some more, there is some new information that is less specific to our application.
It seems that after the failed login, even the mouse can't give focus to QLineEdit fields. The physical keyboard can still type in these fields, but the on-screen keyboard cannot. If we login properly and then logout, the fields work properly again, and they also start working again after clicking or touching the QComboBox and selecting a different item.
I suspect this may be a bug specific to the OS (window manager) or the version of Qt we're using.
Are there any known bugs like this in RedHat 8.4 or Qt 5.15? We have been using this same touchscreen driver and application code in previous releases that were on Scientific Linux 6.4 and did not have this issue, which is why I believe the problem lies in Qt or RedHat.
-
I wonder if there's something grabbing the keyboard, mouse, or otherwise changing focus unexpectedly. QApplication::focusChanged() is good for catching focus changes when they happen.
The QEvent::Focus(In|Out|AboutToChange) and QEvent::Grab(Mouse|Keyboard) events can be picked up via the event filter.
-
I wonder if there's something grabbing the keyboard, mouse, or otherwise changing focus unexpectedly. QApplication::focusChanged() is good for catching focus changes when they happen.
The QEvent::Focus(In|Out|AboutToChange) and QEvent::Grab(Mouse|Keyboard) events can be picked up via the event filter.
@jeremy_k After adding those events to the event filter, I don't see anything suspicious grabbing the mouse or keyboard. I don't get a single grab event anywhere. Plenty of focus changing, but none that look out of place.
