Details
-
Task
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
None
-
None
Description
In handlers, grabPermissions provides finer-grained control over grab transitions, turning it into more of a negotiation. In QQuickItem we have setKeepMouseGrab and setKeepTouchGrab, which are similar to not having any of the Approves flags on grabPermissions (i.e. ApprovesTakeOverByItems, ApprovesTakeOverByHandlersOfDifferentType etc. are not set to true). Also, why are mouse and touch different? Any QEventPoint can have its exclusive grabber set, and if the item wants to keep the grab, that's probably independent of which device is being used. I think we had keepMouseGrab first and added keepTouchGrab just for completeness, but that's not the last event type that can be grabbed.
If we add the ReactsToGrabbedPoints flag, that's probably going to be relevant to item subclasses too.
A few years ago I was thinking that handling pointer events in item subclasses ought to become obsolete, so none of this legacy stuff matters: composition is the way forward. Event handling is a facet, not part of the definition of any item. Items are visual, and event handling should be added on by adding handler instances. But it doesn't seem realistic, because of the "classic OO" instincts of C++ programmers: they always want to subclass and override virtual functions to change behavior.
Attachments
Issue Links
- relates to
-
QTBUG-73262 it's confusing that TapHandler.gesturePolicy affects event propagation
- Reported
-
QTBUG-92944 input problems in DynamicTexture example
- Closed
-
QTBUG-94012 handlers in underlying or parent items should be able to avoid reacting when a higher-z or child item already handled it
- Closed