Details
-
Bug
-
Resolution: Done
-
P2: Important
-
None
-
5.10.0 Beta 4
-
None
-
2f91b0f25fff560de27632ec9d947c890426664e
Description
A possible (oversimplified) Button implementation:
import QtQuick 2.10 import Qt.labs.handlers 1.0 Rectangle { id: root property alias label: buttonLabel.text signal tapped implicitHeight: buttonLabel.implicitHeight * 1.2 implicitWidth: buttonLabel.implicitWidth * 1.3 width: implicitWidth; height: implicitHeight color: th.pressed ? "tomato" : "wheat" border.color: "beige" Text { id: buttonLabel anchors.centerIn: parent } TapHandler { id: th objectName: "button" onTapped: root.tapped() } }
The use case:
import QtQuick 2.10 import Qt.labs.handlers 1.0 Rectangle { id: scene color: "#221" width: 320; height: 240 TapHandlerButton { label: "tap me" onTapped: console.log("TADA") TapHandler { objectName: "override" gesturePolicy: TapHandler.WithinBounds onTapped: console.log("tada?") grabPermissions: TapHandler.CanTakeOverFromHandlersOfSameType } } }
The "override" handler is the second handler to get the event, even though the user's intention was to be first, to override behavior, by being "on top of" the internal handler. That is because it is appended to the Rectangle->private->extra->pointerHandlers vector, in QQuickItemPrivate::data_append(), after the Button component is completed. If this were using MouseAreas instead, it would be the other way around. Even if a declaration of an Item with multiple MouseAreas inside occurs in a single QML file, the one which is declared on the bottom would get the press event first, because of having a higher Z order. So it seems we should make the ordering of Pointer Handlers consistent with that.
QQuickSinglePointHandler::wantsPointerEvent() currently returns false for any point which is already grabbed by another handler, so even though the "override" handler does see the event, it does not try to steal the grab.
Now that we have grabPermissions it should be easier for the control author and the user to negotiate grab stealing. But of course if the "override" handler is actually visited first, there may not be a need for it.
The next problem in this kind of scenario is how can the user's handler delegate some functionality to the internal handler...
Attachments
For Gerrit Dashboard: QTBUG-64692 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
212214,3 | prepend PointerHandler children of Items so the last is visited first | 5.10 | qt/qtdeclarative | Status: MERGED | +2 | 0 |