Details
-
Suggestion
-
Resolution: Unresolved
-
P5: Not important
-
None
-
5.5.1, 5.6, 5.7
-
None
Description
The current QTouchEvent does not provide enough information when used in a scenario like the QGraphicsView framework. At the scene level, QTouchEvents are split into sub events so that only touching points are delivered to items on the scene. This works well enough, but it means that at the scene event handling level, there is no in-built way to ask if any or all of the points were processed by items on the scene. For TouchUpdate/End/Cancel events, the call to the super class event handler
QGraphicsScene::event(event);
in any sub class re-implementations always results in a QTouchEvent which has isAccepted() returning false when a QGraphicsItem on the scene consumed some or all of the individual touch points. Only the TouchBegin events where ALL the points are consumed by an item return true in the end for isAccepted true on the original QTouchEvent.
In a true multi touch environment, where it should be possible to interact with items and the scene at the same time this makes it very difficult because you have no easy way of working out which points were consumed lower down the hierarchy. If the individual points had an isAccepted state, then during normal event propagation it would be easy to split out QTouchEvents in user code. Presumably, this could be done relatively easily and without affecting existing behavior, as code which is aware at that level would not need to look at the isAccepted state of the main QTouchEvent.
Attachments
Issue Links
- depends on
-
QTBUG-72173 Refactor the QEvent hierarchy to make input events more like QQuickPointerEvents in Qt 6
- Closed