aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickevents_p_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Pass QWheelEvent data to QML engine via QQuickWheelEvent pointerVolker Hilsheimer2021-01-151-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Passing events as objects or references in signal parameters requires copying, and we removed the broken copy semantics from QEvent for Qt 6 as much as possible. QVariant::fromValue still allows creation of a QVariant from a type that doesn't have a (public) copy constructor, which is why this passing of a QWheelEvent through a QVariant to QML went unnoticed. While QWheelEvent is a gadget and thus supposed to be invokable from QML, it's still a QEvent. Most QEvents are not gadgets - like QKeyEvent, QMouseEvent, QTouchEvent. We have QQuick*Event QObject wrappers instead to provide access to the low level event data from QML. So, use a single QQuickWheelEvent object instead to pass the data to QML, that class is designed for exactly that prupose. We need to copy the data anyway, and since we don't need to create/destroy the wrapper object for each event, this has no practical overhead. Extend the QQuickWheelEvent to provide access to the phase information of QWheelEvent as well, and simplify the reset() method. Note: making the QQuickWheelEvent store the QWheelEvent directly would allow passing calls to setAccepted through to the QWheelEvent. That is left for a future cleanup, and another reason for not passing events around as copies. Fixes: QTBUG-89594 Change-Id: Id86a9b30c5a8c7c50091e464e368568a7f5ca2ea Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 2b15a1fbe2f26a090f79ab5aa238f375bc67fda3) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Don't copy QKeyEvent instances, store the data explicitlyVolker Hilsheimer2020-11-161-15/+32
| | | | | | | | | | QEvent is a polymorph type, and even though it has a copy constructor, we shouldn't use it. Use the pattern as in QQuickMouse/WheelEvent. Change-Id: I26ab7b831e1e8dd156c32417f74bc7d800bcf71c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove QQuickPointerEvent etc.; deliver QPointerEvents directlyShawn Rutledge2020-09-181-445/+3
| | | | | | | | | | | | | | | | | | | | | | | QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Replace QTouchEvent::TouchPoint with QEventPointShawn Rutledge2020-07-151-8/+8
| | | | | | | | | | | | It's a cosmetic change at this time, because we have declared using TouchPoint = QEventPoint; Also replace Qt::TouchPointState enum with QEventPoint::State. Task-number: QTBUG-72173 Change-Id: Ife017aa98801c28abc6cccd106f47a95421549de Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QQuickPointerDevice in favor of QPointingDeviceShawn Rutledge2020-06-231-123/+16
| | | | | | | | | | | | | | ...and generally deal with changes immediately required after adding QInputDevice and QPointingDevice. Also fixed a few usages of deprecated accessors that weren't taken care of in 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad. Task-number: QTBUG-46412 Task-number: QTBUG-69433 Task-number: QTBUG-72167 Change-Id: I93a2643162878afa216556f10808fd92e0b20071 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-02-211-0/+2
|\ | | | | | | | | | | | | Conflicts: tests/auto/quick/qquickmousearea/BLACKLIST Change-Id: I3de2c6377d57f5f9204d2cfc688d50a7a0b4150c
| * Make qtdeclarative compile with -no-feature-tableteventShawn Rutledge2020-02-201-0/+2
| | | | | | | | | | | | | | | | Amends 8e822e981d91e688799c8670f11dfdf6aaf9e0d1. Fixes: QTBUG-82168 Change-Id: I8d849747a3394ca05d62b674a725d45165f081eb Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* | Add major version to all Q_REVISIONsUlf Hermann2020-02-191-11/+15
| | | | | | | | | | Change-Id: Id72fbe10c16de61bd847773d0055d83cfe03f63c Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-02-171-10/+61
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/imports/qtqml/plugin.cpp src/qml/qml/qqml.h src/qml/qml/qqmlmetatype.cpp src/qml/qml/qqmlmetatype_p.h src/qml/qml/qqmltypeloader.cpp src/qml/types/qqmlbind.cpp src/quick/items/qquickitemsmodule.cpp tests/auto/qml/qqmlecmascript/tst_qqmlecmascript.cpp Change-Id: I52548938a582cb6510271ed4bc3a9aa0c3c11df6
| * Deliver QTabletEvents to pointer handlersv5.15.0-alpha1Shawn Rutledge2020-02-111-10/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At this time, there are not yet any specialized handlers to do anything specifically with tablet events; but we demonstrate how to use HoverHandler to detect the type of stylus in use, and how to use PointHandler to draw on a Canvas. Unfortunately, events of types TabletEnterProximity and TabletLeaveProximity are not delivered to the window, only to QGuiApplication. So HoverHandler can detect when the stylus is moved out of its parent Item (as long as it's still hovering over the tablet surface), but cannot detect when the stylus leaves the tablet completely. In Qt 5 that would require a custom application subclass (see qtbase/examples/widgets/widgets/tablet/tabletapplication.cpp). Fixes: QTBUG-79660 Change-Id: I81fdb99082dc41c0455085e6b6d3952402bf8742 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Add a few missing includesAllan Sandfeld Jensen2020-02-141-2/+4
|/ | | | | | | Revealed after removing redundant includes in QtCore. Change-Id: I1639a8012bf14c9f97f52cae3584dda5cef74b38 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add PointerScrollEvent QML registrationShawn Rutledge2020-01-131-1/+5
| | | | | | | | | | Since registration of this type was neglected in 5.14 (yet was still usable in WheelHandler.onWheel() { } anyway), it didn't get included in cc1a604c704f848927b3fa0a97b0a50b0b79d2a4. Task-number: QTBUG-81302 Change-Id: I24645f4f982310655901c45aca6cdccfbafa911e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Avoid initializing QFlags with 0 or nullptrAllan Sandfeld Jensen2019-11-221-3/+2
| | | | | | | | | It is being deprecated. Change-Id: I844bd92af85bc53a8fc0371408d05277bd49f511 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Handle -no-feature-shortcutFriedemann Kleint2019-10-181-1/+3
| | | | | | | | | | | | | Preparing for the extraction of QGuiShortcut, the shortcut feature will changed to follow the convention of using QT_REQUIRE_CONFIG(shortcut) in the affected class headers. Add the required exclusions to prevent compile errors when disabling shortcuts. Task-number: QTBUG-76493 Change-Id: Icad95584ae12aa97a56b56ef27206cef1b1ba48f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Specify parameters of type registration in class declarationsUlf Hermann2019-09-261-0/+30
| | | | | | | | | | | | | | | | | | | | | Using this technique we can automatically register all necessary revisions and minor versions of a type, using the metaobject system. This greatly reduces the potential for mistakes and resulting incompatibilities between versions of imports. We assume that for each type we need to register all revisions of its super types and its attached type, and that the revisions match. That is, if you import version X of type A, you will also get version X of its attached type and of any super types. As we previously didn't take these dependencies into account when manually registering the types, a number of extra revisions are now registered for some types. Potentially, we can now generate the qmltypes files at compile time, using moc. Change-Id: I7abb8a5c39f5e63ad1a0cb41a783f2c91909491b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Add WheelHandlerShawn Rutledge2019-04-271-0/+1
| | | | | | | | | | | | | It can be used to change any qreal property of its target Item in response to wheel rotation, or it can be used in other ways that involve bindings but without a target item. [ChangeLog][QtQuick][Event Handlers] Added WheelHandler, which handles mouse wheel rotation by modifying arbitrary Item properties. Fixes: QTBUG-68119 Change-Id: I247e2325ee993cc1b91a47fbd6c4ba0ffde7ad49 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Declare the enum so it can be passed to the QML sideAndy Shaw2018-11-301-0/+1
| | | | | | | | | In order for the enum value to be passed to the QML side then it needs to be registered so it can be picked up. This fixes the signals using QQuickEventPoint::GrabTransition, such as PointerHandler's grabChanged. Change-Id: I387930d50f03fee867b3d869618525d44173b538 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Merge remote-tracking branch 'origin/5.11' into 5.12Liang Qi2018-10-291-0/+2
|\ | | | | | | | | | | | | | | | | Conflicts: src/imports/settings/qqmlsettings.cpp src/quick/items/qquickwindow.cpp tools/qmlplugindump/main.cpp Change-Id: I96fedbc773a110374baed79a0b7de92d65df0ed6
| * Warn, don't crash during nested delivery of mouse or touch pressesShawn Rutledge2018-10-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | If during delivery of a mouse press, user code calls qApp->sendEvent() with another mouse press, then when delivery of the nested event is finished, we call QQuickPointerMouseEvent::reset(nullptr). Then when delivery of the original mouse press resumes, crashes are possible because most of the code assumes that QQuickPointerEvent::m_event is not null during delivery. Change-Id: Id65b1f2f64351e40d03bcd4f4d16693d616729da Fixes: QTBUG-70898 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * Add some null pointer checks to avoid some rare crashesv5.11.2Jan Arve Sæther2018-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The crashes happened because somebody was calling processEvents() from a mouse/touch event handler that was running for a long time. If we called processEvents() from the onPressed handler, and we released the mouse while still not having returned from the onPressed handler, it meant that we were actually delivering the release event before the press event was fully delivered... This should normally not be a problem, but QQuickWindow is reusing the QQuickPointerEvent object for each incoming QEvent, which meant that when we were delivering the release event, it would reuse (and overwrite) the QQuickPointerEvent that the press event handler is still using.... This then caused some assumptions that the code made to be wrong. This only avoids the crashes, and doesn't really fix the "out-of-order" delivery and the state inconsistency that this can lead to (e.g. mouse button states might be still wrong). But on the other hand, it is not the recommended way of making a long-running handler not block the application. The proper way is to create a thread that will run in the background, so that there would be no need to call processEvents() in the event handler. Change-Id: I6fa5d4f5748ef30d082a210f03ef382922bd4b29 Task-number: QTBUG-65454 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * Remove const from QQuickPointerEvent::device propertyShawn Rutledge2018-07-271-1/+1
| | | | | | | | | | | | | | | | | | A property never has const pointer as its type. Getting this wrong also causes problems with the QML type registration not matching the actual type. Task-number: QTBUG-61749 Change-Id: Ic3c47499cc4dff6df0beecf5b1413c76509ca6f5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Remove redundant Q_ENUM declarations in QQuickEventPointShawn Rutledge2018-09-281-3/+0
| | | | | | | | | | | | Task-number: QTBUG-70374 Change-Id: Ic382bef1f6155ecd4d4b0a5a4e7b28b3dcb257ff Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Fix revisioning of QQuickMouseEvent::flagsKai Koehne2018-09-011-1/+1
| | | | | | | | | | Change-Id: If8f8a2f889eba1287664988519a68ee9acf259c6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Rename QQEventPoint::GrabState to GrabTransitionShawn Rutledge2018-08-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix property declarationsSimon Hausmann2018-08-201-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | It does not make sense to declare a property that has a setter and mark it as constant. Moc also complains about it and notes how the constant attribute is ignored. Therefore we might as well remove it from the declaration. Amends a9b9875acc6155f85558bb27cdb75f2dda5e2b66 Change-Id: Ib78d6e9c5e3415bc2a3dc26477d1d2a4e5b4dcfe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Mark non-notifying properties in event types CONSTANTShawn Rutledge2018-08-061-41/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Event objects are valid only within the context of a JS callback that receives the object as a signal parameter, and the object will not change during the runtime of that callback. It's not true that the properties will never change, because event objects are pooled and reused; but the QML is not allowed to keep a reference to an event, so the property changes during this reuse are not meant to be seen. QQuickMouseEvent is similar, and its properties were already marked CONSTANT. Change-Id: I4985e4a27bf192779629311eb8c6c1f63d22df3e Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | TapHandler: emit eventPoint from the tapped signalsShawn Rutledge2018-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Any JS callback using one of these signals probably needs to know which button was tapped. We do not want to require TapHandler.point.pressedButtons to tell a lie (temporarily hold the previous state even though a button was actually released). We could add a releasedButtons property, but it would be a bit weird to have it holding state indefinitely between events. We could add just a button parameter to these signals, which would not be so bad, but emitting the whole eventPoint opens up other possibilities, like doing filtering in JS based on the device. To be able to get the device property of the event in QML, it must not be a const pointer. Q_PROPERTY(const type* ...) is so far unprecedented in Qt Quick; and the device has only const properties anyway. This reverts 8dc02aab72a714b5195ccc641fbfb534c3ae9e98 Task-number: QTBUG-61749 Task-number: QTBUG-64847 Change-Id: I09067498b22cc86e9f68c5ff13d6aa5447faba3d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Deliver QNativeGestureEvent via deliverSinglePointEventUntilAcceptedShawn Rutledge2018-06-211-0/+1
| | | | | | | | | | | | | | | | This just simplifies the code a little, and also enables event filtering during delivery to Items. Change-Id: I407dc9a19207f977b574f2a92f5da892e8752987 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Add QQuickPointerScrollEvent as a wrapper for QWheelEventShawn Rutledge2018-06-201-0/+47
| | | | | | | | | | | | | | | | | | We'll use this for delivery of QWheelEvents to both Items and Pointer Handlers. Later we can perhaps use it for QScrollEvent too. Task-number: QTBUG-68119 Change-Id: I04cbbc85fe1a86cf5fd0374d353876f7e6140b70 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Add QQuickSinglePointEvent as intermed. base for QQMouseEvent and othersShawn Rutledge2018-06-201-28/+26
| | | | | | | | | | | | | | | | | | | | | | | | For now we already have QQuickPointerNativeGestureEvent; and in the future, there may be other single-point events such as wheel events. It's handy to reuse the implementations of several virtual functions and the m_point storage. Also format braces more consistently in function implementations. Change-Id: I4b514610b9ed2bd23b7e9a6f1acf826ebd9ebc45 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | QQuickPointerEvent: guard all access to m_eventShawn Rutledge2018-05-291-3/+3
|/ | | | | | | | | | | QQuickWindowPrivate::pointerEventInstance(device, eventType) returns a pointer event which is not based on a QEvent: m_event will be null. This is useful for delivering hover events, but the qDebug operator<< crashes when it tries to print the timestamp, if we don't check for null m_event. Change-Id: Id3a93a1ffcae78cbf287f724da9c012a6b546b0b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix build without features.gesturesTasuku Suzuki2018-05-141-0/+8
| | | | | | Change-Id: Id2fb6419be9a35ddaa24106d3022e72070cb908d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* Fix crash when using drag with Drag.AutomaticFriedemann Kleint2018-04-261-0/+2
| | | | | | | | | | QQuickPointerTouchEvent::m_event is 0 when calling QQuickPointerTouchEvent::isPressEvent(). Add a convenience function with a check returning the Qt::TouchPointStates. Task-number: QTBUG-44976 Change-Id: I2433ec3c56adeda2de190ca46aed8413a1357c55 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickWindow: skip mouse synthesis for touch events from trackpadsShawn Rutledge2018-03-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A trackpad is primarily a mouse-emulating device, which can also recognize gestures, and furthermore can send raw touches iff it is asked to. So, every touch event from a trackpad is likely to be followed by a mouse or gesture event (especially when the MouseEmulation capability confirms that it is able to do that). Therefore mouse event synthesis is redundant. In this bug scenario, MultiPointTouchArea enables touch events within its rectangular bounds. A Flickable is on top. As you flick with two fingers on the trackpad, macOS sends touch events with two touch points (because MPTA enabled touch events) and also a series of QWheelEvents as it recognizes the flick gesture. The Flickable receives mouse events sythesized from one touch point, and reacts as if you were dragging with one finger on a touchscreen, while it simultaneously also reacts to the QWheelEvents. Meanwhile the remaining touchpoint falls through to the MPTA underneath; so the user ends up interacting with both at the same time and making the Flickable jump around besides. This patch just fixes the jumpiness in Flickable: it will no longer receive the synth-mouse events, so it will not be dragged, and will react only to the wheel events. But MPTA still gets the touches. Task-number: QTBUG-66329 Change-Id: I6f535a2c9e47bcb284eaf9ae1fdaa39f8b510af9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* allow DeviceType and PointerType enums 16 bits each; bit packingShawn Rutledge2018-03-021-11/+13
| | | | | | | | | | | | Now in QQuickPointerDevice, the types, flags and capabilities take up 64 bits together, and we reserve enough bits to add more types later. In C++11 enums can be strongly typed by "inheriting" an integer type, so we do that. They are signed because button count and maximum touch points are signed, and because MS compilers do that by default with enums. Change-Id: I45f27bcceeef275cbee256472b35f78fbdeeaad6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* use the override keyword consistently and correctly (clang-tidy)Shawn Rutledge2018-02-271-2/+2
| | | | | Change-Id: If9e28d143f8cba3df3c757476b4f2265e2eb8b2a Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* init variables where they are declared when possible (clang-tidy)Shawn Rutledge2018-02-261-23/+18
| | | | | | | | clang-tidy -p compile_commands.json $file -checks='-*,modernize-use-default-member-init,readability-redundant-member-init' -config='{CheckOptions: [{key: modernize-use-default-member-init.UseAssignment, value: "1"}]}' -header-filter='qtdeclarative' -fix Change-Id: I705f3235ff129ba68b0d8dad54a083e29fcead5f Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-3/+3
| | | | | | | | | | | | | 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>
* Add support for getting the flags from the original mouse eventAndy Shaw2018-01-181-2/+7
| | | | | Change-Id: Ifdf0b8cb43b1e88f3931f49ac6ca72019548ddcf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove deprecated grabber()Jan Arve Sæther2017-11-081-1/+0
| | | | | | | We already have grabberItem() that serves the same purpose Change-Id: I137ebab8ecc2c3924e55015e28735eefc79c2ae8 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* PinchHandler: add native pinch gesture supportShawn Rutledge2017-09-291-1/+40
| | | | | | | | | macOS generates QNativeGestureEvents for 2-finger trackpad zoom and rotation gestures. Now PinchHandler will react to them in the same way that PinchArea does. Change-Id: I4c7dab1d3561d20897e3671f4eb68d01ea06b9bd Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* improve documentation of the PointerHandler base classes and indexShawn Rutledge2017-09-291-1/+0
| | | | | | | 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-9/+9
| | | | | | | | 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>
* Remove isValid from QQuickPointerEventFrederik Gladhorn2017-08-301-1/+0
| | | | | | | | | | | We don't seem to have any use for invalid points, so let's remove the concept. The debug code first checks the valid property, but then unconditionally accesses the event, showing that we never had any invalid event in there in the first place. Change-Id: I5f8aac16c519f06a151198902cc98097eafacaa8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Do not break qtlocation when integratingJan Arve Saether2017-07-131-0/+1
| | | | | | | | Once pointerhandlers are merged it should be fixed in qtlocation, and then this should be removed. Change-Id: I8b6364fff762417ac45ea76bfe1c06836c7fdf15 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/dev' into wip/pointerhandlerJan Arve Saether2017-07-111-18/+8
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: examples/quick/shared/LauncherList.qml src/quick/items/qquickevents.cpp src/quick/items/qquickevents_p_p.h src/quick/items/qquickwindow.cpp tests/auto/quick/touchmouse/tst_touchmouse.cpp Change-Id: Id692d291455093fc72db61f1b854f3fc9190267b
| * Revert "Temporarily restore QQuickPointerDevice::pointerEvent() accessor"v5.9.0-rc2v5.9.0-rc1v5.9.0Shawn Rutledge2017-05-201-7/+0
| | | | | | | | | | | | | | | | | | | | This reverts commit ee6b07b3ce8ba80632868181d45d96253acb1064. This is to be integrated after the qtlocation change to remove the dependency on this private function. Task-number: QTBUG-57253 Change-Id: I756681fb2595d1326b7e5206bac57ccc318c0a46 Reviewed-by: Liang Qi <liang.qi@qt.io>
| * Temporarily restore QQuickPointerDevice::pointerEvent() accessorShawn Rutledge2017-05-121-0/+7
| | | | | | | | | | | | | | | | | | This can be reverted as soon as the relevant qtlocation change is integrated. Task-number: QTBUG-57253 Change-Id: I72b71f61ba8fe421ac57c963801176098fe9f11c Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
| * Move pointerEvent instance to QQuickWindowJan Arve Saether2017-05-101-18/+7
| | | | | | | | | | | | | | | | | | | | | | | | With two or more windows, if events are being delivered to each, the grabbers can be different in each. We need unique instances of the QQuickPointerEvent objects for each window to avoid losing the grab state in the parent window while delivering a synthesized event to a subwindow, for example. Change-Id: I51da1212d573853969e32ad78f5b219d979a8a5c Task-number: QTBUG-57253 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Fix some problems with MouseDblClick handlingJan Arve Saether2017-05-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sequence of events delivered from a double click is: [Press,Release,Press,DblClick,Release] The problem was that a DblClick was delivered just like a press event, so it would clear the passive grabber that was established because of the former Press event. When the Release event then got processed, there was therefore a risk that the Release event was not delivered to the passive grabber. The fix is to not deliver DblClick events at all to handlers, and to not deliver DblClick to items if the former Press event was accepted by a handler. Change-Id: I49c0e32ef4e33f7b6014d35dc065da2527b94779 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 23:29:46 +0000