Priority: Not Evaluated
Affects Version/s: None
Fix Version/s: None
Component/s: Quick: Controls 2
and QQuickMouseEvent is just not the way to go here for several reasons:
- we invite the user to write a JS handler instead of declarative QML
- the user needs to know low-level details about when to ignore the event to let it keep propagating
- QQuickMouseEvent is not the right type to handle touch or tablet events
- QQuickMouseEvent doesn't have a QPointingDevice, so the user doesn't have that mechanism to disambiguate event types
- legacy Controls code didn't even bother setting QQuickMouseEvent::source(): hard to believe, but true
- functions like QQuickTextArea::mousePressEvent(QMouseEvent *) rely on touch->mouse synthesis instead of handling pointer events directly
Removing these will probably allow us to remove quite a bit of (buggy) event-handling code, and even the QQuickPressHandler struct, which seems to be only used in TextArea and TextField. And we will get better separation of concerns: TextArea's concern is text editing, not running its own timer for the long-press, popping up context menus, and whatever else these ugly JS functions would get used for in the real world.
But since they have been there until now, we'll have to deprecate them first. Hopefully it will turn out that there aren't too many users, and nobody gets too vocal about not being able to control event propagation if we take away the ability to set the accepted flag directly. But for the simple case of handling right-clicks and long presses, a TapHandler should be a much better fit... after QTBUG-101398 is fixed. And ideally you would not need to set both gesturePolicy and grabPermissions, either.