aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/handlers/qquickpointerhandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Doc: fix grabPermissions and other enumeration propertiesShawn Rutledge2018-09-141-2/+21
| | | | | | | | | | | | * grabPermissions is a flags property, not bool. * Add a list of the possible grabPermissions values. * Fix two other places where \qmlproperty enum was used instead of enumeration. * acceptedButtons, acceptedDevices, acceptedModifiers and acceptedPointerTypes are flags properties, not plain int. Change-Id: I6f49dcc1e1762e913e4989b208380d64899630a6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Rename QQEventPoint::GrabState to GrabTransitionShawn Rutledge2018-08-311-7/+7
| | | | | | | | | | | | | | | | | | | This enum represents a transient state transition, and only sometimes corresponds to the current grab state of an event point. For example after exclusive grab has been canceled, the current state is that there is no exclusive grab: it doesn't make sense to remember that the way it got there was by cancellation. There was an idea to add a grabState property, but not all values would be eligible. An EventPoint can be exclusively grabbed by one item or handler at a time, and by multiple passive grabbers at the same time, so even a Q_FLAG would not fully express all possible states. Besides, there is already an exclusiveGrabber property, and we could add a passiveGrabbers list property if we had a real need. So adding a grabState property seems unlikely, and therefore is not a good enough reason to keep this enum named as GrabState. Change-Id: Ie37742b4bd431a7e51910d79a7223fba9a6bd848 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* MultiPointHandler::wantsPointerEvent: reset if different cand countShawn Rutledge2018-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We always intended to "start over" with event delivery when the number of touchpoints changes. Change 48011c2dfeb83b4fe717034d4b3c353714fead48 began this process, but in addition to QQuickWindow delivering the event to all items and their handlers in reverse paint order, ignoring existing grabs, the handlers themselves have responsibility to act as if it was an initial press whenever the number of relevant touchpoints changes; and because QQuickWindow starts over, handlers do not need to rely on passive grabs to retain interest in one point at the time when a transition to a different number of points occurs. For example, DragHandler by default handles just one point, so if you press one point such that it takes a passive grab and adds that point to m_currentPoints, then you press a second finger within the bounds of the same parentItem, the DragHandler should not go on "wanting" the first point anymore, because a two-finger gesture is different, and not suitable for the DragHandler unless its maximumPointCount >= 2. Even if the second point is released, QQuickWindow will "start over" with delivery, so a multi-point handler does not need to rely on retaining a passive grab to handle the transition from two points back to one again. This also helps enable smoother transitions between different gestures: e.g. in the map.qml manual test, you can drag one finger and transition from dragging to pinching and back while the second finger is pressed, dragged and released. Change-Id: Id9b8f30029ed1ff9fd2d64a5e413a47055622083 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix PointerHandler constructors and destructorsShawn Rutledge2018-07-271-6/+2
| | | | | | | | | | | | | - Constructors should take QQuickItem* not QObject* to be symmetric with the parentItem() accessor (and other code) which assumes its type - Use header initialization everywhere possible - Reorder variables to minimize padding (somewhat) - Remove empty destructor bodies (the compiler can write them) - Remove override and virtual from destructors in accordance with https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override Change-Id: I682a53a803d65e29136bfaec3a5b534e975ecf30 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Rearrange docs: Pointer Handlers -> Input HandlersShawn Rutledge2018-07-261-2/+1
| | | | | | | | | | | | | | | At QtCS 2018 we decided to rename Pointer Handlers to Input Handlers and include the Keys attached property as part of this set (since we plan to have attached-property pointer handlers too, eventually). It's no longer a module, it's included in Qt Quick 2.12. We need to start promoting Input Handlers and reducing the visibility of legacy stuff like MouseArea and MultiPointTouchArea (in the hope of being able to deprecate them eventually). Task-number: QTBUG-66651 Change-Id: I801351ac2531191cbb1faac9318441c67a109af6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* Finish renaming pointDistanceThreshold to margin (including doc image)Shawn Rutledge2018-07-241-1/+1
| | | | | | | | | Followup to da722fb448f06cf43780e6f857a1ccd9f07176d6 Task-number: QTBUG-68077 Change-Id: I93322949018091e453297164ef1838619d19ee57 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Martin Smith <martin.smith@qt.io>
* Rename Pointer Handlers to Input Handlers (as a concept)Shawn Rutledge2018-07-121-8/+8
| | | | | | | | | | | | | | | | This is a documentation change to alleviate some confusion that we've seen during the Tech Preview period. It doesn't make sense to actually rename the base class though, because it is intended to handle QQuickPointerEvents, not QEvents. The reason for that is that refactoring the QEvent hierarchy has to wait until Qt 6. So maybe in Qt 6 we can remove QQuickPointerEvent and have a QQuickInputHandler base class which handles QInputEvents; but for now, this conceptual renaming seems about as far as we can go. Task-number: QTBUG-66651 Change-Id: I84a41dc282c480d08f4d4a0d9a857e37e074aa7a Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* Add cat. logging in wantsEventPoint; improve FlickableInterop testShawn Rutledge2018-06-291-1/+4
| | | | | | | It was too hard to debug behavior in this test. Change-Id: Iaec9534cca17bdd90b94cfa8fa8b21b7026839ae Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Replace MultiPtHndlr.pointDistanceThreshold with PointerHandler.marginShawn Rutledge2018-06-291-1/+38
| | | | | | | | | | | | | | | | It's not just useful for PinchHandler: TapHandler has a good use for it too. But unfortunately if the handler's parent Item has a custom mask, we don't have a way to augment the mask with a margin; so if margin is set, we assume the bounds are rectangular. QQuickMultiPointHandler::eligiblePoints() now calls wantsEventPoint() rather than bounds-checking the point directly: this adds flexibility, potentially allowing an override in subclasses, if we need it later. Task-number: QTBUG-68077 Change-Id: I65c95f00c532044a5862654e58c9c5f8c973df81 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add HoverHandler to detect a hovering mouse pointerShawn Rutledge2018-06-281-3/+9
| | | | | | | | | | Detect whether the handler's parent contains the mouse, while the point property tracks the event point (position etc.) Task-number: QTBUG-68072 Change-Id: Ica99332596eab3e344852a11f1ceb7aaf6348c86 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* PointerHandler.grabChanged signal: add stateChange parameterShawn Rutledge2018-06-271-5/+7
| | | | | | | | | To make grabChanged signal useful, it's necessary to know whether the Pointer Handler has acquired or lost the grab. This patch fixes that. Task-number: QTBUG-68074 Change-Id: I29398d2bb5b27b8541197f23c3043ee86cad7c76 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Move wantsEventPoint() up from SinglePointHandler to QQPointerHandlerShawn Rutledge2018-06-201-0/+5
| | | | | | | | We want to be able to call it from the upcoming QQuickItemPrivate::anyPointerHandlerWants function. Change-Id: I15ef60303fa56f43e66b16c8dd0f4102070536d0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix non-initialized class memberJesus Fernandez2018-06-201-4/+4
| | | | | | | | >>> Non-static class member "reserved" is not initialized in this constructor nor in any functions that it calls. Coverity-Id: 190209 Change-Id: Ia1c07ff16b2015d99ab15f387ac6cc687703fcbb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Refactor QQuickPointerHandler: add private implementation classShawn Rutledge2018-05-151-38/+88
| | | | | | | Follow the usual pattern in preparation for making this class public. Change-Id: I8330cdda27e131a5f93723d4cf4c53a9f7630434 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQuickPointerHandler: make classBegin and componentComplete protectedShawn Rutledge2018-03-271-1/+9
| | | | | | | | | They are public in QQmlParserStatus but don't need to be public here. Also de-inline the default implementations, because this class will be public C++ API eventually. Change-Id: Ic7dfbec853e3d20f45b361401f710dedb5eae416 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* doc: Correct mostly linking errorsMartin Smith2018-02-231-3/+3
| | | | | | | | | This update corrects many qdoc warnings, mostly of the "Can't link to..." variety, but there were also a few qdoc comments added. As of this update, the qdoc warning count is 46 in QtDeclarative. Change-Id: Icf2d34c7ce7010ebfd9b474feacfe8af42f3fd5f Reviewed-by: Martin Smith <martin.smith@qt.io>
* QQuickPointerHandler: add virtual onTargetChanged()Shawn Rutledge2018-01-121-0/+2
| | | | | | | | To be overridden in handlers which need to know when this happens, to avoid connecting to the targetChanged() signal. Change-Id: I51432b69d05fd541eb62e0cd01f4019e336816ac Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* PointerHandler: add grabPermissions, enforce in setExclusiveGrabShawn Rutledge2017-11-141-9/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As soon as we enable the concept that PointerHandlers can use passive grabs to lurk, monitor all movements, and then steal the passive grab, they can fight over the grab. For example if there are two items with PinchHandlers, and two or more touches occur within bounds for both, then each update event can cause the other PinchHandler to steal the grabs and become active. So we replace stealing with negotiation: the handler which wants to take over the grab checks its own flags to see whether that's allowed, and the handler which is about to lose its grab also has the right to approve or deny the takeover (just as QQuickItem has had keepMouseGrab and keepTouchGrab for a long time.) Additionally, if one handler wants to cancel another handler's grab without taking over (simply set the grabber to null), it must be approved. A single-point handler can simply call setExclusiveGrab, with the expectation that permission may be granted or denied. A multi-point handler only wants to grab all points if grabbing all of them will be allowed, otherwise grab none; so it calls canGrab on each point to check beforehand. Thus, when two handlers are competing for the same grabs, one or both can be prevented from stealing from each other, or from Handlers in general, or from Items, or some combination. Change-Id: I5c733b2b8995ce686da0be42244394eeee82a268 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix Logically dead codeJesus Fernandez2017-10-271-1/+1
| | | | | | | | | | | The indicated dead code may have performed some action; that action will never occur. In QQuickPointerHandler::onGrabChanged(QQuickPointerHandler *, QQuickEventPoint::GrabState, QQuickEventPoint *): Code can never be reached because of a logical contradiction Coverity-Id: 182646 Change-Id: Ic3ccffddf3052337d22d5dd7fabb8bfa7af35dbe Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* improve documentation of the PointerHandler base classes and indexShawn Rutledge2017-09-291-12/+68
| | | | | | | also QQuickPointerEvent and QQuickPointerDevice Change-Id: I8bdb7c26cf6a5775a77dbf748c47c170270c5fff Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* rename QQuickEventPoint pos properties to positionShawn Rutledge2017-09-051-2/+2
| | | | | | | | For consistency we always spell it out, although it does make some of these properties inconveniently verbose. Change-Id: I64a08c3aa261c0ab89e09472dd47510abafbf7ca Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Doc: Fix PointerHandler QML docsTopi Reinio2017-08-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | qquickpinchhandler.cpp:138: warning: Missing property type for QQuickPinchHandler::minimumX qquickpinchhandler.cpp:151: warning: Missing property type for QQuickPinchHandler::maximumX qquickpinchhandler.cpp:164: warning: Missing property type for QQuickPinchHandler::minimumY qquickpinchhandler.cpp:177: warning: Missing property type for QQuickPinchHandler::maximumY qquickpinchhandler.cpp:194: warning: Missing property type for QQuickPinchHandler::minimumTouchPoints qquickpinchhandler.cpp:198: warning: Missing property type for QQuickPinchHandler::active qquickpointerdevicehandler.cpp:107: warning: Missing property type for QQuickPointerDeviceHandler::acceptedModifiers qquickpointerhandler.cpp:47: warning: C++ class QQuickPointerHandler not found: \instantiates QQuickPointerHandler qquickpointerhandler.cpp:176: warning: Missing property type for QQuickPointerHandler::enabled qquickpointerhandler.cpp:255: warning: Missing property type for QQuickPointerHandler::parent qquicktaphandler.cpp:175: warning: Missing property type for longPressThreshold qquicktaphandler.cpp:235: warning: Missing property type for gesturePolicy qquicktaphandler.cpp:252: warning: Missing property type for pressed qquicktaphandler.cpp:329: warning: Missing '\endqml' qquicktaphandler.cpp:340: warning: Missing property type for tapCount qquicktaphandler.cpp:353: warning: Missing property type for timeHeld Change-Id: I8a5bd0ec7c5603573f39f5b5f1f24d5735ba98dd Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Start over with event delivery when touchpoint releases occurShawn Rutledge2017-05-221-0/+1
| | | | | | | | | | | | | | | | | | | | The new rule is that when the number of touchpoints changes, we start over with event delivery as if the touch had just begun, to give more opportunities to hand off processing from one item or handler to another. And MultiPointTouchArea can now handle the handoff: for example in tests/manual/pointer/pinchDragFlingMPTA.qml when the user is pressing three fingers, the PinchHandler is active; when the user then lifts one finger, the MPTA can resume handling the two remaining touchpoints as if they were just pressed. The change in QQuickMultiPointerHandler::wantsPointerEvent is both a behavior change and an optimization: released points aren't eligible; but if some points are released, then pressed, updated and stationary points are all eligible. And, figure this out without looping over the points twice. Change-Id: I26b7593de8e72b471adfec4a4482dd87a8288442 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Don't allow one handler to cancel another's grab, unless it is stealingShawn Rutledge2017-05-151-0/+3
| | | | | | | | | | | | | | | This is required to keep the tst_flickableinterop touchDragSlider test passing after the change to TapHandler to never give up passive grab. And QQuickEventPoint::setGrabberPointerHandler(nullptr, true) will just go ahead and allow TapHandler to cancel the grab which the DragHandler currently has at that time, when you have pressed the TapHandler but started dragging so that the drag threshold is exceeded. (Perhaps this points to an API problem.) For now, we at least can enforce the rule in QQuickPointerHandler::setExclusiveGrab that if grab is false, it won't nullify the grab of a different handler. Change-Id: I7c93188cfdce51b3b5a17c13e5efc7fcbd123d4b Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* PointerHandler: add wants/declines logging to qt.quick.handler.dispatchShawn Rutledge2017-04-271-1/+5
| | | | | | | | | and remove the similar "delivering to" log from QQuickItem. It's more useful to know whether delivery will continue rather than simply that we made an attempt. Change-Id: I58c37fb50d4d0c99ef6aa68662ab304194b6d128 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* TapHandler: do not react to stationary touchpointsShawn Rutledge2017-04-211-1/+1
| | | | | | | | | | In autotests, stationary points normally have invalid position. A TapHandler does not need to react to them anyway. But we must also avoid having a grab cancelation due to a stationary point, and that applies to all PointerHandlers in general. Change-Id: I99493ad7d859e0c4ef155afc699aa34f28ffdbc7 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* PointerHandlers always ungrab if wantsPointerEvent returns falseShawn Rutledge2017-03-301-2/+9
| | | | | | | | | | That means the PinchHandler for example will require exactly requiredPointCount touchpoints. If it was satisfied, then one finger is released, it must give up its grabs so that another PointerHandler has a chance to take over. Change-Id: I28e32d6d3f255c7de8023f054dc480528bb14852 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* unify handler grab state handling into onGrabChangedShawn Rutledge2017-02-211-44/+55
| | | | | | | | | | | | | | | | | | | | | | onGrabChanged and handleGrab looked redundant. It was also not clear how important it is for handlers to react to passive ungrabs, overrides or cancellations. Rather than debating about when to call one of these and when not to, let's centralize the responsibility in QQuickEventPoint (because the grabber pointers are stored there, so it's the ultimate destination of any grab change), and let's notify all the relevant handlers about all changes, with enough information that each handler can decide for itself what's important and what isn't. But so far most handlers don't need to override this virtual. The base class QQuickPointerHandler takes care of setting the active property to false, rejecting the eventpoint, and unsetting keepMouseGrab and keepTouchGrab whenever grab is lost; and emitting grabChanged or canceled as appropriate to notify any QML code which needs to know. Subclasses mainly care about the change of active state: they must initiate active state themselves, and may react when it reverts to false. Change-Id: I6c7f29472d12564d74ae091b0c81fa08fe131ce7 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* DragHandler: keep the grab (prevent stealing) when draggingShawn Rutledge2017-02-171-0/+10
| | | | | | | | | | | | | Whenever the DragHandler gets an exclusive grab, it needs to prevent a parent Flickable (for example) from taking over that grab. Since it waits until the drag threshold is exceeded in an allowed dragging direction, this does not prevent the Flickable from being draggable in the other direction. We restore the state of keepTouchGrab and keepMouseGrab when ungrabbing. Change-Id: Id9d456c99322e0cb6996d1f690b38fcd6becc6f9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* notify all passive-grabbing PointerHandlers when exclusive grab changesShawn Rutledge2017-02-101-0/+7
| | | | | Change-Id: I45df7abdbd91e068a69101ed27e2ec44272e3899 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* start making explicit exclusive or passive grabsShawn Rutledge2017-02-101-6/+28
| | | | | Change-Id: I4a6e3c72d69e893fec2e39f4faab24af6d00c7e0 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQuickPointerHandler::setGrab: don't emit grabChanged if it didn'tShawn Rutledge2016-12-301-4/+4
| | | | | | | | When requested to grab, it was emitting this signal and calling onGrabChanged every time. Change-Id: I32ce80e4d6ff8b8e950b5d2f977bd737e31b8ac8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* DragHandler active property replaces dragging; same as grabbingShawn Rutledge2016-12-291-3/+1
| | | | | | | | | | | | | | | | | If a QQuickPointerSingleHandler grabs a point, it's definitely in the active state: doing something with the point. (The converse is not always true though: e.g. TapHandler can sometimes detect a tap without ever grabbing.) In DragHandler, the "dragging" property means the same as "active": we always grab when dragging, to be sure to get the updates. So the "dragging" property is removed because it's redundant. In QQuickPointerHandler we don't say that "wanting" an event is the same as being active, because 1) it won't necessarily grab right away and 2) every handler which was active should "want" the release event, yet it needs to setActive(false) as soon as it's done processing it. Change-Id: Ie010db54714a7914109da6469e79865f9a0a18e4 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Don't assume that target is the parent itemJan Arve Saether2016-12-291-17/+25
| | | | | | | | | | | To summarize: A pointer handler always gets its pointer events from its parent item. It applies its effect (drag, pinch, ...) on the item referenced to by the target property. By default, target refers to the parent, but that is not always the case. In addition to this we also have to handle the case when the target is null Change-Id: If62108abf0aeb713906bf88472ad9a32a74efff6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Deactivate the handler when wantsPointerEvent returns falseJan Arve Saether2016-12-091-0/+2
| | | | | Change-Id: I34db4be279a68a7bf66adb604b12f8aff3c1bac4 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* add virtual QQuickPointerHandler::onGrabChanged and signal grabChangedShawn Rutledge2016-12-091-0/+4
| | | | | | | | Some handlers will need to react to gaining or losing a grab, in both C++ and QML. Change-Id: I25b94800e3eaeabb0782315c679813ec735d4d51 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* add virtual QQuickPointerHandler::onActiveChangedShawn Rutledge2016-12-091-0/+1
| | | | | | | | | | | | | and override it in PinchHandler. Many handlers will need to do something in response to change in active state, so calling a virtual when the state changes and overriding it in subclasses is more efficient than for subclasses to connect to the activeChanged signal. This also helps us control the signal emit order: the subclass can deal with any consequences (such as changing its own properties) before activeChanged is emitted. Change-Id: I6d05643e8facfd1941aa9152de6865932edb1b3a Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQuickPointerHandler: add read-only parent propertyShawn Rutledge2016-11-241-0/+12
| | | | | | | | | | The parent is the Item in which the handler is instantiated. It cannot (so far) be reassigned to a different item, so this is not the same as QQuickItem's parent property: it's rather a convenience to get the QObject parent and cast it. Change-Id: Ib352213589532f45f104c8d83f04fd14107a4a20 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* add QQuickPointerHandler::handleGrabCancel; call in setGrabShawn Rutledge2016-10-171-2/+15
| | | | | | | | | | | | | Only one handler can be the grabber at one time, so we need to ensure that we notify the others when they lose the grab. Also handle this in QQuickPointerSingleHandler: forget m_currentPointId, so that wantsPointerEvent will not continue to "want" the same ID. Also add the canceled(QQuickEventPoint *point) signal, which is one of the four possible "state signals" (press, update, release, cancel) but which we didn't commit to adding yet. Change-Id: I46256acb75ece863d84e812af2d30cb0b12e3c1f Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
* QQuickEventPoint: rename itemGrabber -> grabberItem etc.Shawn Rutledge2016-09-191-3/+3
| | | | | | | | QQuickWindow::mouseGrabberItem already existed, so we have a precedent for "specific thing which grabs" to come after the word Grabber. Change-Id: I65847ee0a005fac9b6292b9b91bb16f5f180e9bb Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
* add QQuickPointerHandler::active propertyShawn Rutledge2016-08-241-1/+12
| | | | | | | | By default, a handler is active whenever wantsPointerEvent() returns true, and inactive when it returns false. Change-Id: I627762ba8f4eed167f675f220ffaed79c93c8448 Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
* QQuickEventPoint::grabber: allow grabbing either an item or a handlerShawn Rutledge2016-08-231-4/+3
| | | | | | | QQuickPointerHandler and QQuickItem have only QObject in common. Change-Id: I8fb68cc1779f42049db1e0eb5ff60019a1c674d3 Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
* add QQuickPointerHandler::wantsPointerEventShawn Rutledge2016-08-231-2/+12
| | | | | | | | | | | | | | | | | | | There will be an inheritance hierarchy of pointer handlers. The base class doesn't have enough information to know whether an event should be accepted or rejected, so it cannot change the state of the event, so there's no way for a subclass to benefit from the base class's checking of m_enabled, if it has no way to communicate to the subclasses. An intermediate class has more information which contributes to the decision of whether to accept or reject, but still not enough: the leaf class must make the final decision. So we need a virtual bool function, at least as an implementation detail, even though from the perspective of event delivery, there's only one outcome: the event is accepted, or not. We have eschewed public bool functions to avoid ambiguity during delivery: there is no return value to pay attention to, only the accepted state of the event. Change-Id: Ieaca4968fce0064f80b5460aa4c10b431036e12a Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
* add QQuickPointerHandler::targetContains(QQuickEventPoint*)Shawn Rutledge2016-08-161-0/+7
| | | | | | | Most handlers will need to check this. Change-Id: I44858c0ac4ccb58a9a2de70382e3954af6554ef3 Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
* QQuickPointerHandler: add eventPos() accessorShawn Rutledge2016-08-161-0/+5
| | | | | | | | | This is to compensate for the fact that the EventPoint does not store the Item-localized position, only scenePos. Either it should store it or we have to recalculate it in each Handler. Change-Id: I5b02814d5fd7930bb32b547c1af00808b8e23b80 Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
* Introduce QQuickPointerHandler: base class for nested event handlersShawn Rutledge2016-08-151-0/+120
They will be Tech Preview in 5.8, so they shouldn't be available unless you explicitly import them. Task-number: QTBUG-54824 Change-Id: I290854a4e2b76e2cdfef5c216c7fdeb47fbcd390 Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-07 09:01:17 +0000