aboutsummaryrefslogtreecommitdiffstats
path: root/tests/manual/pointer/content
Commit message (Collapse)AuthorAgeFilesLines
* tst_flickableinterop: test buttons with all gesturePolicy valuesShawn Rutledge2017-05-151-1/+1
| | | | | Change-Id: If3d9e10bb54fc75a7e72bc6367de3e083611a45f Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* DragHandler: allow parent to be different from targetShawn Rutledge2017-04-271-7/+9
| | | | | | | | | | | | | | | The most obvious way to implement a Slider is to allow dragging the knob - as on a real-world physical sliding potentiometer. But to make it easier on a touchscreen, it should be possible to touch anywhere along the slider's travel, as on a QtQuick.Controls 2 Slider. For that purpose, we need to respond to events within the bounds of one Item while actually dragging a different Item (the knob). It's similar to the way that PinchHandler can handle pinch gestures within one Item while transforming another (which may be too small to get both fingers inside). Change-Id: Iac9a5f11a7a45e22d93fe52bf62d157c48d72d3d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* PH manual tests: better object names for easier debuggingShawn Rutledge2017-04-201-1/+2
| | | | | Change-Id: Icd5b9dc5fa00c98cc40b03e9d72f6b28fc51a579 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* add ScrollBar manual testShawn Rutledge2017-03-071-0/+160
| | | | | | | | | | | | It demonstrates that DragHandler's grabs work well enough, so that you can grab the knob and drag it even while the cursor goes outside the window. Also the TapHandler for detecting clicks or taps within the "trough". And for completeness, the FakeFlickable example needed scrollbars, to prove that it's possible to build all the flicking and scrolling behaviors with only PointerHandlers. Change-Id: I9d9323b1f583a02e0157edb85b6bffbe1652711f Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* TapHandler manual test: demonstrate tapped signalShawn Rutledge2017-03-071-1/+1
| | | | | | | | | | | Missiles are too expensive to launch in continuous sprays anyway. Also, it's too hard to keep holding down the "balloons" button if we use policy DragThreshold. This is better to have on the fighters button, since the usual use case is that ballons are launched first, and cheap enough to launch continuously. Change-Id: I3b52556b81afad9fb7ec1a4b1dec4dde3bab104c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* TapHandler: add gesturePolicyShawn Rutledge2017-02-093-2/+159
| | | | | | | | | | | | | | Until now it behaved as if this was set to DragThreshold: give up on the tap as soon as you are clearly dragging rather than tapping. But that's not what is normally wanted when building a Button control, for example. So provide 3 options: give up past the drag threshold, when the pointer goes outside the bounds, or when it's released outside the bounds. The longPressThreshold also constrains all three cases: holding (or dragging) for too long will not result in an immediate cancellation, but it also will not be a tap gesture. Change-Id: I95aec978e783892b55371391a27642751d91d9ff Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* add flickableWithHandlers manual testShawn Rutledge2017-02-094-0/+376
| | | | | | | | to verify that Flickable still works after the changes in event delivery logic, even when it contains a mix of various Areas and Handlers. Change-Id: Ibf68bc8b403718c87c7e647b17837f2a8e4e3f0e Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* add FakeFlickable manual testShawn Rutledge2017-02-081-0/+89
| | | | | | | | Demonstrate that DragHandler, MomentumAnimation and a couple of Items are enough to implement most of Flickable's functionality. Change-Id: I59dae38dc66c16813385aa6c00e3a1a834520f31 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* add MomentumAnimation as a manual test / experimentShawn Rutledge2017-02-081-0/+71
| | | | | | | | It could be exposed as a new type of animation, but for now it's just an experiment. Change-Id: Ic900752a90ccae93270e27399f370f5d47495f74 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* DragHandler active property replaces dragging; same as grabbingShawn Rutledge2016-12-291-1/+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>
* Introduce DragHandlerShawn Rutledge2016-08-261-0/+117
A handler for dragging Items around by touch or mouse. Change-Id: Id83fea568095eb6374f3f1abc6f550d81f3731df Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>