aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/handlers/qquickpointerhandler_p.h
Commit message (Collapse)AuthorAgeFilesLines
* QQuickPointerHandler: make classBegin and componentComplete protectedShawn Rutledge2018-03-271-4/+4
| | | | | | | | | 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>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-1/+1
| | | | | | | | | | | | | From now on we prefer nullptr instead of 0 to clarify cases where we are assigning or testing a pointer rather than a numeric zero. Also, replaced cases where 0 was passed as Qt::KeyboardModifiers with Qt::NoModifier (clang-tidy replaced them with nullptr, which waas wrong, so it was just as well to make the tests more readable rather than to revert those lines). Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QQuickPointerHandler: implement QQmlParserStatusShawn Rutledge2018-02-081-1/+6
| | | | | | | | componentComplete() is useful to inform the handler that its parent Item is complete. Change-Id: Iec0e171d647dad45e0af2e0878f540d6f76f53bf Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQuickPointerHandler: add virtual onTargetChanged()Shawn Rutledge2018-01-121-0/+1
| | | | | | | | 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-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QQuickWindowPrivate::deliverTouchCancelEvent: deliver to handlers tooShawn Rutledge2017-02-231-0/+1
| | | | | | | | Now that onGrabChanged() is unified, we have a means to tell the handler when it loses its grab due to a touch event being canceled. Change-Id: Idf3649242233ac7fb8c1fa80ad257ee14b861090 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make all handler constructors explicitJan Arve Saether2017-02-211-1/+1
| | | | | Change-Id: I17b3865d70bdc07912d7454b459dea40b9c98df0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* unify handler grab state handling into onGrabChangedShawn Rutledge2017-02-211-3/+1
| | | | | | | | | | | | | | | | | | | | | | 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/+2
| | | | | | | | | | | | | 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/+1
| | | | | Change-Id: I45df7abdbd91e068a69101ed27e2ec44272e3899 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* start making explicit exclusive or passive grabsShawn Rutledge2017-02-101-2/+4
| | | | | Change-Id: I4a6e3c72d69e893fec2e39f4faab24af6d00c7e0 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Don't assume that target is the parent itemJan Arve Saether2016-12-291-3/+4
| | | | | | | | | | | 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>
* add virtual QQuickPointerHandler::onGrabChanged and signal grabChangedShawn Rutledge2016-12-091-0/+2
| | | | | | | | 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-1/+2
| | | | | | | | | | | | | 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/+3
| | | | | | | | | | 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-0/+4
| | | | | | | | | | | | | 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>
* add QQuickPointerHandler::active propertyShawn Rutledge2016-08-241-1/+7
| | | | | | | | 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>
* add QQuickPointerHandler::wantsPointerEventShawn Rutledge2016-08-231-1/+2
| | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | | 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/+1
| | | | | | | | | 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/+101
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-06-24 17:52:06 +0000