summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qevent.cpp
Commit message (Collapse)AuthorAgeFilesLines
* doc: use \note in QKeyEvent documentationTor Arne Vestbø2021-09-151-8/+8
| | | | | | Pick-to: 6.2 Change-Id: I0924f5a540ab5e58f7830c1af099ce6e44287811 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Fix deprecation of QMouseEvent::source() and flags()Shawn Rutledge2021-08-271-0/+2
| | | | | | | | | | Amends 53496e67f0b78645c6080e9218c7a36bc5a9d76d: - move flags() out of the QT_DEPRECATED_SINCE block in the header - add QT_DEPRECATED_SINCE block around source() implementation Pick-to: 6.1 6.2 Change-Id: Id52fa6b04a13efbede3e6ac440060f90b283e773 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Doc: Ensure deprecated APIs in Gui are documented as suchNico Vertriest2021-07-261-13/+47
| | | | | | | | | | | Added missing #if-ery and deprecation macros to a QFont constructor that was only documented as deprecated. Fixes: QTBUG-94521 Fixes: QTBUG-95310 Pick-to: 6.2 6.1 Change-Id: I3d0418a3f7dca191a9068cc22627fe4deb7c53c5 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add note about precision of QNativeGestureEvent::delta; fix in Qt 7Shawn Rutledge2021-07-151-3/+7
| | | | | | | | | | | We keep QVector2D storage Qt 6 BC (to avoid making QNativeGestureEvent larger), but in Qt 7 we should return exactly the same value as given (for what it's worth, in spite of this being overkill for panning a reasonable distance). Change-Id: Iecbd4c9b60ad9ae5e0466c7027b038ddb85b8c8b Pick-to: 6.2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Rename QNativeGestureEvent::deltas() to delta(); clarify docsShawn Rutledge2021-07-141-14/+39
| | | | | | | | | | | | | | | | | In QPanGesture this is called delta(). OTOH we have QWheelEvent::pixelDeltas(). Delta is a vector, and there's only one (with two components). Native gestures hold incremental values: e.g. the pinch gesture event provides an incremental amount of either zooming or rotation (so most events have QNativeGestureEvent::value() very close to 0). It's the same with the pan gesture's delta(). Add better docs for swipe and pan gestures. Change-Id: Ia147c7c9a22e084c3700b1620dec46427d792bd1 Reviewed-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Change QNativeGestureEvent::deltas() to QPointFShawn Rutledge2021-07-141-1/+1
| | | | | | | | | | | | | It came up during 6.2 API review that we prefer all floating-point API to be double-precision on 64-bit platforms, despite the awkwardness of representing a displacement vector with something called a "point". The docs for QPointF explicitly state "A QPointF object can also be used as a vector: Addition and subtraction are defined..." Amends 31f90e99b8f04d9a228c5a0b01319b3f112c1490 Change-Id: I01029661f2586640cbf846f49df164c176d17f7a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Show positions in QDebug operator<<(dbg, QHoverEvent*)Shawn Rutledge2021-07-051-19/+30
| | | | | | | | | | In Qt 6, QHoverEvent is a QSinglePointEvent and carries more information than it did in Qt 5. Task-number: QTBUG-94971 Change-Id: I55b271e8741081ed9074f687b08f4111142a1bf0 Pick-to: 6.2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Remove mentioning of Qt::MidButtonKai Köhne2021-06-171-1/+1
| | | | | | | | It's only Qt::MiddleButton in Qt 6. Pick-to: 6.1 6.2 Change-Id: Ia68bad910c617993e30e3ed1e117192469ec50eb Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Revert "Use Pressed/Released eventpoint state with native gesture begin/end"Fabian Kosmale2021-06-031-13/+0
| | | | | | | | | | | This reverts commit 0336f08fec906af7e907d07d990a097a9a1d8726. Reason for revert: This breaks tst_qquickpinchhandler; We no longer seem to construct a QNativeGestureEvent of type EndNativeGesture with it. Change-Id: I942fa099d5c5a1c757accde0c67e407809ce2d72 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Use Pressed/Released eventpoint state with native gesture begin/endShawn Rutledge2021-06-031-0/+13
| | | | | | | | | | | | The QSinglePointEvent is mostly responsible for setting QEventPoint::state(); but in this case we need to decide based on Qt::NativeGestureType, so it needs to be refined in the QNativeGestureEvent constructor. Fixes: QTBUG-94178 Change-Id: I9799fe5b8fea71f934311ae2f3bb8e033d132ec5 Reviewed-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add fingerCount to qDebug output for QNativeGestureEventShawn Rutledge2021-06-011-1/+1
| | | | | | | | | | Followup to 31f90e99b8f04d9a228c5a0b01319b3f112c1490. The number of fingers involved in a gesture will likely become a key feature to make different behaviors distinct. Change-Id: Ib41b2fa7ab4ea7d008a6479c018b3d475a62a8fd Reviewed-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Doc: Use \deprecated instead of \obsoletePaul Wicking2021-05-261-3/+3
| | | | | | Task-number: QTBUG-93990 Change-Id: I4e512354a49dde6678ca89cabc56bc76ba666bb3 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QWindow: synthesize a QContextMenuEvent from relevant mouse eventsVolker Hilsheimer2021-05-061-5/+0
| | | | | | | | | | | | | | | QWindow receives keyboard originated context menu events, so it should also receive events originating from a right-button mouse event. Remove the incorrect statement about the special acceptance flag for context menu events. There is no such thing, the event gets delievered after the corresponding mouse press/release event. Fixes: QTBUG-59988 Task-number: QTBUG-93486 Change-Id: I148310440604e74f600932cc1898fa152c483a61 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Revert "Add grabber context pointers"Shawn Rutledge2021-04-291-1/+1
| | | | | | | | | | | This reverts commit 40330b8f0a717098982d1f54f34a18a8262b1f55. It was a bad idea to use QFlatMap here, because it is a sorted map, but we need to keep the passive grabbers in the same order as the grabs happened. So need to go back to an earlier version of the patch that uses two parallel QLists. Pick-to: 6.1 Change-Id: I9e6013c2565986fe1eb9fd754f8259766f83bee5 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add grabber context pointersShawn Rutledge2021-04-281-1/+1
| | | | | | | | | | | | | | In Qt Quick we now need to keep track of which QQDeliveryAgent is responsible when a point is grabbed, either passively or exclusively. When we re-deliver to that grabber, we need to do it via the same agent, so that the same scene transform is used, and the grabber will see the event in the correct coordinate system. It's easier to track this mapping here instead of in a separate map in Qt Quick. Pick-to: 6.1 Task-number: QTBUG-92944 Change-Id: I69f769c694d0da24885cdf4087e5032022bff629 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add storage for (pixel) deltas and fingerCount to QNativeGestureEventShawn Rutledge2021-04-271-2/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | It's not clear now whether trackpad gestures on Windows will need to be so different than on macOS; however, any reasonable int value can be stored in a qreal, and in Qt Quick we like to use floating-point numbers for all "real" values and measurements. So since we need to add more storage, and quint64 m_intValue has never been used, we now replace it with a QVector2D, which should have the same size. The intended use is that PanNativeGesture will include a displacement, probably in pixels, by which the viewport or some target item should be panned or moved. The naming of deltas() is flexible enough to support any gesture with some incremental 2D valuators, though, just as value() has gesture-dependent semantics. fingerCount() will be useful for Qt Quick pointer handlers to filter out events that have the wrong number of fingers, e.g. to require that either a 3-finger pan gesture or 3 individual touchpoints are required to activate DragHandler { minimumPointCount: 3 } (assuming we implement pan gesture support in DragHandler). Fixes: QTBUG-92179 Task-number: QTBUG-92098 Change-Id: I5462aea9047beed6e99075294a62011edd8a59f5 Reviewed-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Doc: Fix various documentation issuesTopi Reinio2021-03-161-0/+6
| | | | | | | | | | - Document QIODeviceBase - Document QPointerEvent::points - Fix linking issues Task-number: QTBUG-90662 Change-Id: Ib123d5708953b22e01f95c82626b39a49fff95b2 Reviewed-by: Nico Vertriest <nico.vertriest@qt.io>
* Make qDebug output for QTabletEvent similar to that for QMouseEventShawn Rutledge2020-12-041-10/+7
| | | | | | | | | | | | | | | | | | Reuse operator<<(QPointingDevice*) and move the button state right after the event type. Now it's easier to follow when a QTabletEvent is not accepted and a mouse event is synthesized: qt.quick.pointer QQuickWindowPrivate::deliverPointerEvent - delivering QTabletEvent(TabletPress LeftButton pos=100,100 z=3 xTilt=25 yTilt=35 pressure=0.5 dev=QPointingDevice("Wacom Intuos3 6x8 Pen stylus" Stylus id=13 seat=30002 ptrType=Pen caps=Position|Pressure|MouseEmulation|Hover|XTilt|YTilt uniqueId=499602d2)) qt.quick.pointer QQuickWindowPrivate::deliverPointerEvent - delivering QMouseEvent(MouseButtonPress LeftButton pos=100,100 scn=100,100 gbl=3739,1029 dev=QPointingDevice("Wacom Intuos3 6x8 Pen stylus" Stylus id=13 seat=30002 ptrType=Pen caps=Position|Pressure|MouseEmulation|Hover|XTilt|YTilt uniqueId=499602d2)) Change-Id: If22f1c07d32f595d0444513b49635218c08a300d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Output source in debug operator of QMouseEventFriedemann Kleint2020-11-251-0/+4
| | | | | | | | Task-number: QTBUG-88678 Task-number: QTBUG-46412 Pick-to: 6.0 Change-Id: If9282f5b845ef16ff7e7ce523f78e3b8adfbef90 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Disable copying and assigning of QEventVolker Hilsheimer2020-11-191-10/+0
| | | | | | | | | | | | | | Polymorphic classes should not be copied. However, we do rely on event copying in our propagation logic. So, make the members protected, don't delete them, using a dedicated macro. This way, QMutable*Event classes can be used to make copies. Remove some last usage of copying of QInputMethod(Query)Events. Change-Id: Ia0a8ae4ca9de97dcd7788ca3c6ed930b6460c43a Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Consolidate static_asserts for event sizesVolker Hilsheimer2020-11-171-0/+4
| | | | | | | | | | | | The assertion for size of QMouseEvent and Q(Mutable)SinglePointEvent being equal was previously in QtDeclarative; qtbase should already fail to build if they ever diverge. Having the checks in a single translation unit is enough, qevent.cpp is the obvious choice. Change-Id: I80ad24273738dfde8b165323ac1e790c320c707c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Inline trivial getters for QEvent subclassesVolker Hilsheimer2020-11-131-41/+17
| | | | | Change-Id: Ic0ee4f3e311e1068d23796cee4fe58008a2a8114 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Clean up and pack data members of QEvent classesVolker Hilsheimer2020-11-121-45/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure all bits reported by sizeof for the most important public event classes are used optimally. QEvent is 24bytes large due to default alignment in C++, so we might just as well use bool instead of bitfields for the most important data members. This generates less (and thus smaller and faster) code, and we still have plenty of bits available for future needs. Default the copy constructor and assignment operator, the assert and tracing seem to be relics from the Qt 3/4 days. Note: QEvent's d-pointer is currently unused, with the exception of a hack in QGraphicsView. Removing that would save another 8 bytes through the entire event hierarchy. For the new classes in the QInputEvent hierarchy, apply the same principle. Allocate bits in QInputEvent and QSinglePointEvent to fill the 8-byte aligned space. Using some of those bits for QMouseEvent and QWheelEvent makes sure we don't increase the size for those in spite of additionally reserved bits. As a result of this, several QInputEvent and subclasses become 8 bytes smaller on clang and gcc (with the exception of QNativeGestureEvent) while at the same we have more space for future extensions. The sizeof's for the various classes on different compilers produce these before and after result: clang +/- gcc +/- msvc +/- QEvent 24 0 24 0 24 0 QInputEvent 56 -8 56 -8 48 0 QPointerEvent 80 -8 80 -8 72 0 QSinglePointEvent 96 -8 96 -8 88 0 QMouseEvent 96 -8 96 -8 88 0 QTabletEvent 112 -8 112 -8 96 -16 QKeyEvent 104 -8 104 -8 96 0 QNativeGestureEvent 120 0 120 0 120 0 QWheelEvent 112 -8 112 -8 112 -8 So, with this change we save 8 bytes on gcc and clang for many event types, esp on Linux systems. As a drive-by: replace ulong with quint64, make QTabletEvent data floating point, and rename some variables for clarity. Change-Id: I4cf81c8283262cbf59ee3fb7064a59837332ced7 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Replace ushort -> quint16 in event classesShawn Rutledge2020-11-101-2/+2
| | | | | | | | We used quint32 for 32-bit types and ushort for 16-bit ones, but using explicit bit sizes looks more consistent. Change-Id: I3106dd6ecb2367fef6f8012c28266e1b4b1abf4b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move the remaining QSinglePointEvent ctor to protected; add source argShawn Rutledge2020-11-101-8/+8
| | | | | | | | | | | | | QSinglePointEvent no longer has public constructors: we don't expect users to construct instances, because it's conceptually an abstract base class (even though some subclasses don't add more storage). We give it a Qt::MouseEventSource argument so that m_source won't need to be set in other subclasses. There was some hope of removing MouseEventSource completely, but it hasn't been done, for the sake of avoiding SC breaks. Change-Id: Iea2946699726fb7ac98757b7b8f1b7cfdccc1449 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Improve QPointerEvent qDebug operatorsShawn Rutledge2020-11-091-26/+34
| | | | | | | | | | | | Use the property=value format consistently for the QPointerEvent types. Abbreviate property names for compactness, but show more info. Omit device seatName(), pointerType(), capabilities(), maximumPoints() and uniqueId() when they are uninteresting. In the case of uniqueId() it's uninteresting when it's not valid (-1) rather than when it's 0. Add QMouseEvent::scenePosition(). Change-Id: Ia076c5958e8f7032929517401d332b07d2fd0e78 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Introduce QEvent::isSinglePointEvent()Shawn Rutledge2020-11-071-2/+17
| | | | | | | | | | | | This makes high-level event dispatching easier: for example we often need to cast an event to access getters like button() and buttons(). We can so far assume that any QPointerEvent that is not a QTouchEvent is a QSinglePointEvent; but more explicit type-checking looks safer. Implemented in a similar way as c7f727996909338c3689396160f3060480521846. Change-Id: I980d759e2a7538b6b30fd3bdc3be0c351ec6c246 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move QEventPoint and QPointingDeviceUniqueId out of qeventVolker Hilsheimer2020-11-071-647/+1
| | | | | | | | | | | | | | | | | | | qevent.h/cpp are huge already, no need for more classes. Move QEventPoint into new qeventpoint.h/cpp files, and QPointingDeviceUniqueId into qpointingdevice.cpp; the class is already declared in qpointingdevice.h. Move the documentation of QEventPoint APIs next to the implementation, and document all APIs as properties. Add Q_PROPERTY macro where missing. QEventPoint::device needs a workaround of qdoc due to the type being a pointer-to-const; qdoc doesn't know how to tie a \property to it, but documents it correctly. While at it, move the logging category declarations to the header matching the .cpp file where they are defined. Change-Id: I096e609edbb760b5686d577e7fe47eea0807904e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add QEventPoint::normalizedPosition() to replace normalizedPos()Shawn Rutledge2020-11-031-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 4e400369c08db251cd489fec1229398c224d02b4 we deprecated normalizedPos() because we suspect it's a legacy feature that few users will need. However Qt developers keep bringing up the continued usage in autotests over and over. (It's IMO not wrong to keep testing deprecated functions in autotests, but the warning keeps attracting attention.) Of course it will turn out that normalizedPos() has users; we just don't know how many. One way to look at it is: why should they copy a snippet of code to calculate it, when it costs us so little to continue to provide this accessor. It might also turn out that some users will complain that in Qt 5 it was passed through from the device driver (or at least from the window system API) to the application, and perhaps the replacement will not always work, for example if availableVirtualGeometry() ends up wrong, or there is some strange scenario that generates events that are out-of-bounds for the device that the event professes to come from, so that the "normalized" coordinates also go outside the [0..1] range. We reserve the right to put back the storage in QEventPointPrivate if the need arises; so that's why this function is not inline. We continue to hope that startNormalizedPos() and lastNormalizedPos() are used even less and won't be missed much, because it would be wasteful to store them all the time if only a few users need them. Change-Id: I23ed78843e3f9e16133c5b6f462884a3845f91b6 Reviewed-by: David Skoland <david.skoland@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Address API review comments for QInput/QPointingDeviceVolker Hilsheimer2020-11-031-8/+0
| | | | | | | | | | | | | | - Give default constructor an optional parent, as is standard for QObjects - remove default for QObject parent from inheritance constructor - make QPointingDeviceUniqueId comparison inline, remove superfluous inline of hidden friends - mark read only properties as CONSTANT - remove bit-size from enum types; they are stored in the private, and there are just a few instances; no need to save a few bytes at the expense of performance and code cleanliness Change-Id: Ie7d4a587362714e9d3bc41447cef786bbdb382c6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Make comparison operators hidden friendsVolker Hilsheimer2020-10-281-7/+10
| | | | | | | | | Reduce ADL noise from QKeyEvent, QKeySequence::StandardKey, and QPointingDeviceUniqueId. Task-number: QTBUG-87973 Change-Id: Ib4a3190d03046949acb25b3fe68c611689b82565 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Fix documentation warningsVolker Hilsheimer2020-10-241-1/+1
| | | | | | | | | Declare hidden friends like qdoc expects them, and other signature fixes Document function parameters Remove documentation for removed APIs. Change-Id: I44c1caeed0d40be04612129d074acc30b75f5259 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Make QEvent::setAccepted() virtual; set QEventPoints state the sameShawn Rutledge2020-10-221-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | In Qt Quick, when we deliver an item-specific QTouchEvent that contains only the subset of eventpoints that are inside the Item's bounds, traditionally the Item can accept the event to tell the delivery logic that the event is handled and doesn't need to be delivered further. But an Item cannot be expected to have total scene awareness; so now, the delivery is "done" only when all eventpoints in the original event are accepted. This behavior has been working well enough already due to logic in QQuickWindow that iterates the points and accepts them if the event is accepted; but it seems appropriate to move this enforcement into QPointerEvent itself. Making setAccepted() virtual gives us a useful degree of freedom. Event-handling code should alternatively use QEventPoint:setAccepted() or QPointerEvent::setExclusiveGrabber() to take resonsibility for only a subset of the touchpoints. Another way to put it is that we treat QPointerEvent::setAccepted() as a convenience method: accepting the QEventPoints is what counts (at least in Qt Quick). Change-Id: Icec42dc980f407bb5116f5c0852c051a4521105a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add QSinglePointEvent::exclusivePointGrabber convenience propertyShawn Rutledge2020-10-201-0/+15
| | | | | | | | | | | Since a single-point event (such as a QMouseEvent) only carries one point, it only has one grabber, so we can have a normal Q_PROPERTY. It's named exclusivePointGrabber to avoid shadowing the QPointerEvent::[set]exclusiveGrabber functions that take QEventPoint&. Change-Id: Ie18f1c1849ed057b98f229de7b17b7fc3f3eea36 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QMutableEventPoint::detach: deref old privateFabian Kosmale2020-10-181-0/+2
| | | | | | | | | | After detaching, the current QMutableEventPoint obviously doesn't reference old QMutableEventPointPrivate anymore. Deref it, so that we do not leak memory. Change-Id: I3b59667603d41f452eead9a2db13e1d005f622ec Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Implement move and comparison operators for QEventPointVolker Hilsheimer2020-10-171-4/+48
| | | | | | | | QEventPoints are equal when all data values are equal, the refcount is ignored. Change-Id: I6ef70faf0b12129eaa22bfc1f0a45bab2422d421 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Un-special-case macOS in handling of QKeyEvent::nativeScanCode()Tor Arne Vestbø2020-10-061-4/+0
| | | | | | | | | | | | | | | | | | | | | | | In the porting from Qt 4 to Qt 5 an assumption was made in QKeyMapper that the underlying platform implementation needed the native scan code to be able to resolve the possible keymaps for an event. As a result, the macOS platform plugin started sending key events with a fake native scan code of 1, so that it would still be allowed to map key events. Which in turn led to the documentation of QKeyEvent::nativeScanCode() getting an exception for macOS. Let's clean up this by removing the original assumption, and leave it up to the platforms to decide what information from the key event is needed. QKeyMapperPrivate::possibleKeys() will still call extractKeyFromEvent as a fallback if the platform layer doesn't return any possible keys. Change-Id: I122a45bcec658c45ccc0b2c0671eb264d85d7be6 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Treat a double-click event as an update event with stationary pointShawn Rutledge2020-09-301-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | The sequence is still press, release, press, double-click, release. isBeginEvent() should not be true for a double-click event: the second click began with a normal MouseButtonPress, and the MouseButtonDblClick event is a way of sending updated state to tell the recipient that the second click was special, occurring within such spatial and temporal constraints that it can be interpreted as a double-click. It never has a different position either, because MouseButtonDblClick is a synthetic event occurring at the same position as the second press; so we might as well say its QEventPoint is Stationary. Together, these changes fix tst_controls::Basic::DelayButton::test_mouse in Controls 2, without any changes in qtdeclarative. In QQuickWindowPrivate::deliverPointerEvent(), if isBeginEvent() == true, it delivers to all items under the point position(s) first, and then if all _updated_ points were not accepted, it continues delivery to grabbers; whereas if isBeginEvent() == false, it delivers only to grabbers. isBeginEvent() and QEventPoint::state() are important to that algorithm. Amends 6d6ed64d6ca27c1b5fec305e6ed9b923b5bb1037 Task-number: QTBUG-87018 Change-Id: I95def9704652147540df5cc065354a0fe04ed626 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix qdoc warning: button(s) are members of QSinglePointEventVolker Hilsheimer2020-09-271-25/+0
| | | | | | | ... and documented there already. Change-Id: Ie66362d3b668caf93b100befef08bc91ae8add2f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Get rid of QMutableEventPoint::stationaryWithModifiedPropertyShawn Rutledge2020-09-251-9/+0
| | | | | | | | | | | | | | | | Omitting stationary points from touch events is such a marginal optimization that this code probably isn't worth maintaining. It wasn't implemented correctly this time either, according to the tst_QQuickMultiPointTouchArea::stationaryTouchWithChangingPressure() test. [ChangeLog][QtGui][QPointerEvent] We no longer attempt to avoid delivery of stationary points within QTouchEvent: every pressed point is now included in every TouchUpdate event. Task-number: QTBUG-77142 Change-Id: If1fd666fb3057a17e0dffdd7ca7138693126b02b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix some qdoc warnings: undocumented parametersVolker Hilsheimer2020-09-251-1/+1
| | | | | Change-Id: I5d37f620caccbd1445c99a602b71779bdedd37d3 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix documentation of QPointerEvent::pointsVolker Hilsheimer2020-09-231-15/+6
| | | | | | | As drive-by, fix qdoc warning in related internal documentation. Change-Id: I7716a9b126e38e99dcd11c6af2e91b8ec7bf4346 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Rename is[Begin|Update|End]Event, reimplement in QWheelEventShawn Rutledge2020-09-171-4/+29
| | | | | | | | | | | | | | These states correspond well with ScrollPhase, and this abstraction makes it possible to handle wheel events the same way as mouse events in Qt Quick: on "begin" we deliver to all Items and Handlers until all points (the only point) are accepted; on "update" and "end" we deliver only to the exclusive grabber, if there is one, and to any passive grabbers. Change-Id: I702dbd4f2c1bf5962eb3dbb9e4b725300a00a887 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add more QPointerEvent functions needed in Qt QuickShawn Rutledge2020-09-171-0/+59
| | | | | Change-Id: I87a874477b89eb3f5951930f03e305d896a24c2e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Calculate velocity in QMutEventPoint::setTimestamp() with Kalman filterShawn Rutledge2020-09-161-6/+65
| | | | | | | | | | | | | | This functionality was only in Qt Quick in Qt 5. Now we move it up to QtGui so that every QEventPoint will have a valid velocity() before being delivered anywhere. [ChangeLog][QtGui][QPointerEvent] Every QEventPoint should now carry a valid velocity(): if the operating system doesn't provide it, Qt will calculate it, using a simple Kalman filter to provide a weighted average over time. Fixes: QTBUG-33891 Change-Id: I40352f717f0ad6edd87cf71ef55e955a591eeea1 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Track grab state in QPointingDevicePrivate::activePointsShawn Rutledge2020-09-161-64/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QQuickEventPoint instances were very long-lived and got reused from one event to the next. That was initially done because they were "heavy" QObjects; but it also became useful to store state in them between events. But this is in conflict with the ubiquitous event replay code that assumes it's OK to hold an event instance (especially a QMouseEvent) for any length of time, and then send it to some widget, item or window. Clearly QEventPoints must be stored in the QPointerEvent, if we are to avoid the need for workarounds to keep such old code working. And now they have d-pointers, so copying is cheap. But replay code will need to detach() their QEventPoints now. QEventPoint is useful as an object to hold state, but we now store the truly persistent state separately in an EventPointData struct, in QPointingDevicePrivate::activePoints. Incoming events merely update the persistent points, then we deliver those instead. Thus when event handler code modifies state, it will be remembered even when the delivery is done and the QPA event is destroyed. This gets us a step closer to supporting multiple simultaneous mice. Within pointer events, the points are moved up to QPointerEvent itself: QList<QEventPoint> m_points; This means pointCount(), point(int i) and points() can be non-virtual. However in any QSinglePointEvent, the list only contains one point. We hope that pessimization is worthwhile for the sake of removing virtual functions, simplifying code in event classes themselves, and enabling the use of the range-for loop over points() with any kind of QPointerEvent, not just QTouchEvent. points() is a nicer API for the sake of range-for looping; but point() is more suited to being non-const. In QML it's expected to be OK to emit a signal with a QPointerEvent by value: that will involve copying the event. But QEventPoint instances are explicitly shared, so calling setAccepted() modifies the instance in activePoints (EventPointData.eventPoint.d->accept); and the grabbers are stored separately and thus preserved between events. In code such as MouseArea { onPressed: mouse.accepted = false } we can either continue to emit the QQuickMouseEvent wrapper or perhaps QEvent::setAccepted() could become virtual and set the eventpoint's accepted flag instead, so that it will survive after the event copy that QML sees is discarded. The grabChanged() signal is useful to keep QQuickWindow informed when items or handlers change exclusive or passive grabbers. When a release happens at a different location than the last move event, Qt synthesizes an additional move. But it would be "boring" if QEventPoint::lastXPosition() accessors in any released eventpoint always returned the same as the current QEventPoint::xPosition()s just because of that; and it would mean that the velocity() must always be zero on release, which would make it hard to use the final velocity to drive an animation. So now we expect the lastPositions to be different than current positions in a released eventpoint. De-inline some functions whose implementations might be subject to change later on. Improve documentation. Since we have an accessor for pressTimestamp(), we might as well add one for timestamp() too. That way users get enough information to calculate instantaneous velocity, since the plan is for velocity() to be somewhat smoothed. Change-Id: I2733d847139a1b1bea33c00275459dcd2a145ffc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Doc: Fix documentation issues for event and input device classesTopi Reinio2020-09-101-144/+214
| | | | | | | | | | | | | | * Document the new base classes QPointerEvent and QSinglePointEvent, and move relevant documentation to be located under them. * Replace linking to deprecated functions with their new counterparts. * Remove non-existent function and parameter documentation. * Document QEventPoint::State enum. * Prefer \obsolete over \deprecated and fix the usage. * Document the Capabilities enum in the correct location and add docs for the missing enum values. Change-Id: Ic8f2732f2e90ecbf522cd744c601cedcc574825c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Move grabbing API from QEventPoint to QPointerEventShawn Rutledge2020-09-101-53/+101
| | | | | | | | | | | | | | | | | | | | | | We plan to move storage of the grabbers into QPointingDevice so that QEventPoint will store only data that does not need to persist between deliveries of individual events. These API changes prepare for that. addPassiveGrabber/removePassiveGrabber is a better API than setPassiveGrabbers(), because it will never require constructing a temporary QList just to call the function. Eventually we need to emit signals to notify about grab changes, so it's better to have incremental changes to the list rather than needing to iterate and find differences. Fix up the docs. QEventPoint IDs are no longer written in hex in debug output. That was done in Qt 5 because an ID was a composite of device ID with the OS-provided touchpoint ID; but since the QPointingDevice is always available, it's more readable if the IDs are in decimal. Change-Id: I86b9016d9b28c331ca05c7c108d9788de93fb642 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Give QEventPoint a d-pointer after allShawn Rutledge2020-09-101-20/+133
| | | | | | | | | | I still have doubts that QEventPoint can't be made small enough that copying would be cheaper than reference-counting and all the indirections in now-noninline accessors, but this gives us the usual freedom to change the data members later on. Change-Id: I792f7fc85ac3a9538589da9d7618b647edf0e70c Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Long live QKeyCombination!Giuseppe D'Angelo2020-09-031-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C++20 via P1120 is deprecating arithmetic operations between unrelated enumeration types, and GCC 10 is already complaining. Hence, these operations might become illegal in C++23 or C++26 at the latest. A case of this that affects Qt is in key combinations: a QKeySequence can be constructed by summing / ORing modifiers and a key, for instance: Qt::CTRL + Qt::Key_A Qt::SHIFT | Qt::CTRL | Qt::Key_G (recommended, see below) The problem is that the modifiers and the key belong to different enumerations (and there's 2 enumerations for the modifier, and one for the key). To solve this: add a dedicated class to represent a combination of keys, and operators between those enumerations to build instances of this class. I would've simply defined operator|, but again docs and pre-existing code use operator+ as well, so added both to at least tackle simple cases (modifier + key). Multiple modifiers create a problem: operator+ between them yields int, not the corresponding flags type (because operator+ is not overloaded for this use case): Qt::CTRL + Qt::SHIFT + Qt::Key_A \__________________/ / int / \______________/ int Not only this loses track of the datatypes involved, but it would also then "add" the key (with NO warnings, now its int + enum, so it's not mixing enums!) and yielding int again. I don't want to special-case this; the point of the class is that int is the wrong datatype. Everything works just fine when using operator| instead: Qt::CTRL | Qt::SHIFT | Qt::Key_A \__________________/ / Qt::Modifiers / \______________/ QKeyCombination So I'm defining operator+ so that the simple cases still work, but also deprecating it. Port some code around Qt to the new class. In certain cases, it's a huge win for clarity. In some others, I've just added the necessary casts to make it still compile without warnings, without attempting refactorings. [ChangeLog][QtCore][QKeyCombination] New class to represent a combination of a key and zero or more modifiers, to be used when defining shortcuts or similar. [ChangeLog][Potentially Source-Incompatible Changes] A keyboard modifier (such as Qt::CTRL, Qt::AltModifier, etc.) should be combined with a key (such as Qt::Key_A, Qt::Key_F1, etc.) by using operator|, not operator+. The result is now an object of type QKeyCombination, that stores the key and the modifiers. Change-Id: I657a3a328232f059023fff69c5031ee31cc91dd6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 16:55:54 +0000