summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qevent.h
Commit message (Collapse)AuthorAgeFilesLines
* Port from container.count()/length() to size()Marc Mutz2022-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is semantic patch using ClangTidyTransformator: auto QtContainerClass = expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o) makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container'. <classes> are: // sequential: "QByteArray", "QList", "QQueue", "QStack", "QString", "QVarLengthArray", "QVector", // associative: "QHash", "QMultiHash", "QMap", "QMultiMap", "QSet", // Qt has no QMultiSet Change-Id: Ibe8837be96e8d30d1846881ecd65180c1bc459af Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Rename QHoverEvent ctor pos argument to scenePosShawn Rutledge2022-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The QHoverEvent ctor takes two points: scenePos and globalPos; the first of those is passed to the QSinglePointEvent ctor as _both_ the local and scene pos, which calls QMutableEventPoint::setScenePosition() on the persistent QEventPoint instance, and then detaches before setting ephemeral state. Therefore, we must construct QHoverEvent with scene position, not local position, so that the right value is persisted. To localize a QHoverEvent during delivery, use QMutableEventPoint::setPosition(). This needs to be done repeatedly while visiting multiple widgets or items; the detach() prevents it from being saved in the persistent QEventPoint in QPointingDevicePrivate::EventPointMap. Amends 0a64a044b6c1c44b0a2bb2be5e70fda920f5f6bf Task-number: QTBUG-35409 Task-number: QTBUG-100324 Change-Id: Ic1084e1c3cd384683666ba52fe34f16b9d039877 Pick-to: 6.4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Partly un-deprecate QMouseEvent::source()Ivan Solovev2022-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | | We have deprecated the usage of Qt::MouseEventSource getter in QMouseEvent::source() since 6.0. However, we have a lot of related APIs, where the usage of this enum was not marked deprecated. Also we have a lot of code in qtbase, qtdeclarative and some other modules that rely on those values. In most cases using QMouseEvent::source() is the only way to pass the proper value to the other APIs. This patch un-deprecates the method, so that we can safely identify all of its usages in our code, and port away from it. At the same time, we do not want the client code to use this method, so documentation still mentions it as deprecated since 6.0. Task-number: QTBUG-104857 Pick-to: 6.4 6.3 6.2 Change-Id: I767002aa6dc754fb5a58cf8fbf35774dae9986ed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Do not use QExposedEvent::region() in internal codeIvan Solovev2022-07-131-0/+1
| | | | | | | Task-number: QTBUG-104857 Pick-to: 6.4 6.3 6.2 Change-Id: I5ee41802ecc4d6291aaaa1f0efddd20027c1c1e4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add the qt_class pragma to file listed in sync.profile classnames mapAlexey Edelev2022-06-221-0/+4
| | | | | | | | | This makes header files self-contained and reduces the number of 'sources of truth' for syncqt procedure. Change-Id: I7f5865abc69934603139d23e1b5452da46ccb110 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QEvent: start to de-inline copy ctor and clone() of all subclassesMarc Mutz2022-04-141-145/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no advantage to them being inline: Absent de-virtualisation, clone() is only supposed to be called through the vtable, and the copy ctor is only supposed to be used in the implementation of clone(). And when the compiler de-virtualises, we don't want the code duplication associated with inlining. Enforce this by introducing new macros to hide the boilerplate. This fixes missing out-of-line dtors in: - QSinglePointEvent - QApplicationStateChangeEvent - QFutureCallOutEvent Wrong covariant return in: - QFutureCallOutEvent And missing clone() reimplementations in: - QCloseEvent - QIconDragEvent - QShowEvent - QHideEvent - QDragEnterEvent - QDragLeaveEvent While these don't carry extra data or members, a dynamic_cast of the result of clone() as well as using the expected covariant return value would fail: QShowEvent *e = ~~~; QShowEvent *e2 = e->clone(); // ERROR: converting QEvent* to QShowEvent* Check that reimplementing clone() is binary compatible (covariant returns may change the numerical pointer value returned, cf. https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B). The copy-assignment operator stays inline for the time being, as the goal is to = delete it in the future. This patch covers, roughly, QtCore and QtGui. [ChangeLog][QtGui][QEvent subclasses] Fixed missing clone() reimplementations on QCloseEvent, QIconDragEvent, QShowEvent, QHideEvent, QDragEnterEvent, and QDragLeaveEvent. Task-number: QTBUG-45582 Task-number: QTBUG-97601 Change-Id: Ib8a0519dbe85a7a8da61050d48be338004dfa69a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Deprecate QContextMenuEvent and QMouseEvent ctors without globalPosShawn Rutledge2022-02-051-0/+6
| | | | | | | | | | | | | As with QHoverEvent, it's better to require globalPos rather than "initialized to QCursor::pos(), which may not be appropriate" as the docs have pointed out for many years now. This removes the remaining calls to QCursor::pos() in event constructors. Task-number: QTBUG-52430 Task-number: QTBUG-69433 Task-number: QTBUG-100324 Change-Id: I076dae56f37abaad7085cc95dddee453a80a45f3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add a QHoverEvent ctor taking global mouse position; deprecate the otherShawn Rutledge2022-02-031-0/+6
| | | | | | | | | | | | | | | | | The QSinglePointEvent ctor assumes that the given globalPos is correct, so it was wrong that the QHoverEvent ctor passed along a local position as global. It's better to require globalPos as an argument; and in fact it seems that everywhere we construct a QHoverEvent, global position is available, or possible to get by transformation (which is better than resorting to QCursor::pos()). Also, don't convert to QPoint: pointer events have qreal resolution and there's no reason to truncate them. Fixes: QTBUG-100324 Change-Id: I919455da36265988d3d149eb97563c9ed0d2c660 Pick-to: 6.3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QPointerEvent: de-inline point(i)Marc Mutz2022-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | This function contributed 1.2s of the total 361s (0.34%) to KDDockWidgets compilation time, according to a trace generated by Sergio Martins: **** Time summary: Compilation (146 times): Parsing (frontend): 343.2 s Codegen & opts (backend): 18.1 s **** Templates that took longest to instantiate: [...] 1228 ms: QList<QEventPoint>::operator[] (59 times, avg 20 ms) 1213 ms: QList<QEventPoint>::detach (59 times, avg 20 ms) 1209 ms: QArrayDataPointer<QEventPoint>::detach (59 times, avg 20 ms) 1202 ms: QArrayDataPointer<QEventPoint>::reallocateAndGrow (59 times, avg 20 ms) Task-number: QTBUG-97601 Pick-to: 6.3 Change-Id: I5f4ff9843f7deff9f390c465df28cba3391e048b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix deprecation of QMouseEvent::source() and flags()Shawn Rutledge2021-08-271-1/+1
| | | | | | | | | | 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>
* Add note about precision of QNativeGestureEvent::delta; fix in Qt 7Shawn Rutledge2021-07-151-2/+12
| | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | 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>
* Consistent indentation for all Q_PROPERTYsAndreas Buhr2021-06-241-1/+2
| | | | | | | | Task-number: QTBUG-94407 Pick-to: 6.2 Change-Id: I8c97a0b2de2bed78456322be271724fc47479d83 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add storage for (pixel) deltas and fingerCount to QNativeGestureEventShawn Rutledge2021-04-271-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Replace discouraged Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPEAndreas Buhr2020-11-301-2/+2
| | | | | | | | | | | | | | Q_MOVABLE_TYPE was conceived before C++ had move semantics. Now, with move semantics, its name is misleading. Q_RELOCATABLE_TYPE was introduced as a synonym to Q_MOVABLE_TYPE. Usage of Q_MOVABLE_TYPE is discouraged now. This patch replaces all usages of Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPE in QtBase. As the two are synonymous, this patch should have no impact on users. Pick-to: 6.0 Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Return subclass type from overrides of QEvent::cloneVolker Hilsheimer2020-11-231-34/+34
| | | | | | | | | | C++ allows overrides to return a covariant type, so if calling code has already cast the callee down to the right type, don't require it to cast the returned clone down as well. Pick-to: 6.0 6.0.0 Change-Id: I802f00a3c78e03047046986d0ed0a479b47573b8 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Disable copying and assigning of QEventVolker Hilsheimer2020-11-191-2/+41
| | | | | | | | | | | | | | 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>
* Allow cloning of event objectsVolker Hilsheimer2020-11-171-1/+72
| | | | | | | | | | | | We have use cases for cloning of events, e.g. in the state machine and for event propagation. Provide the means to do so through a virtual method. Adapt QFutureCallOutEvent::clone, which is now an override. No code seems to be using that method. Change-Id: I6864d6597f6de800343c4dc458a7994e84dc6fb4 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Inline trivial getters for QEvent subclassesVolker Hilsheimer2020-11-131-10/+10
| | | | | Change-Id: Ic0ee4f3e311e1068d23796cee4fe58008a2a8114 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Clean up and pack data members of QEvent classesVolker Hilsheimer2020-11-121-38/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-4/+4
| | | | | | | | 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-5/+5
| | | | | | | | | | | | | 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>
* Introduce QEvent::isSinglePointEvent()Shawn Rutledge2020-11-071-1/+4
| | | | | | | | | | | | 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-109/+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-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make comparison operators hidden friendsVolker Hilsheimer2020-10-281-5/+7
| | | | | | | | | 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>
* Make QEvent::setAccepted() virtual; set QEventPoints state the sameShawn Rutledge2020-10-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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/+8
| | | | | | | | | | | 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>
* Implement move and comparison operators for QEventPointVolker Hilsheimer2020-10-171-0/+6
| | | | | | | | QEventPoints are equal when all data values are equal, the refcount is ignored. Change-Id: I6ef70faf0b12129eaa22bfc1f0a45bab2422d421 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Rename is[Begin|Update|End]Event, reimplement in QWheelEventShawn Rutledge2020-09-171-6/+9
| | | | | | | | | | | | | | 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/+31
| | | | | Change-Id: I87a874477b89eb3f5951930f03e305d896a24c2e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Calculate velocity in QMutEventPoint::setTimestamp() with Kalman filterShawn Rutledge2020-09-161-0/+1
| | | | | | | | | | | | | | 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-17/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove QPointerEvent::isPointAccepted() and setPointAccepted()Shawn Rutledge2020-09-141-2/+0
| | | | | | | | They are redundant, not in use, and got added without implementation in a81859a3c8d0f8b4367fc63988e1d653d34ed48a. Change-Id: Ifed1fbf97a8158c2801df09dac47bf1fc90795d4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move grabbing API from QEventPoint to QPointerEventShawn Rutledge2020-09-101-11/+14
| | | | | | | | | | | | | | | | | | | | | | 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-51/+34
| | | | | | | | | | 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/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Introduce QWindow::paintEvent with QPA plumbingTor Arne Vestbø2020-08-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The explicit paint event on QtGui and QPA level allows us to untangle the expose event, which today has at least 3 different meanings. It also allows us to follow the platform more closely in its semantics of when painting can happen. On some platforms a paint can come in before a window is exposed, e.g. to prepare the first frame. On others a paint can come in after a window has been de-exposed, to save a snapshot of the window for use in an application switcher or similar. The expose keeps its semantics of being a barrier signaling that the application can now render at will, for example in a threaded render loop. There are two compatibility code paths in this patch: 1. For platform plugins that do not yet report the PaintEvents capability, QtGui will synthesize paint events on the platform's behalf, based on the existing expose events coming from the platform. 2. For applications that do not yet implement paintEvent, QtGui will send expose events instead, ensuring the same behavior as before. For now none of the platform plugins deliver paint events natively, so the first compatibility code path is always active. Task-numnber: QTBUG-82676 Change-Id: I0fbe0d4cf451d6a1f07f5eab8d376a6c8a53ce8c Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Rename QTabletEvent::m_zTilt to m_zShawn Rutledge2020-08-261-2/+2
| | | | | | | | This is a z coordinate unrelated to tilt, AFAIK. Amends ea2ae140e99bbd21515a99c5480e53129ef843c3 Change-Id: If165df3af290fbe7c2e5bfa94d578175debd53cd Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Introduce QEvent::isPointerEvent()Shawn Rutledge2020-08-251-0/+2
| | | | | | | | | | This makes high-level event dispatching easier: for example in Qt Quick, all pointer events should eventually be delivered to items in a similar way. Implemented in a similar way as d1111632e29124531d5b4512e0492314caaae396. Change-Id: I2f0c4914bab228162f3b932dda8a88051ec2a4d7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove QEventPoint::event() in favor of device()Shawn Rutledge2020-08-241-4/+4
| | | | | | | | | | | | | | | | | | | | | | event()->device() was the most common use case anyway. The idea that the "parent" of a QEventPoint is the QPointerEvent interferes with the ability to copy and move event objects: the parent pointers are dangling unless we use the QPointerEvent subclass destructors to set the points' parents to null. Since there is no move constructor, even returning a QEventPoint from a function by value results in destroying the temporary instance and copying it to the caller's space. So the parent pointer is often useless, unless we do even more work to maintain it when the event moves. If we optimize to avoid copying QEventPoints too much (and perhaps enable exposing _mutable_ points to QML) by storing reusable instances in QPointingDevice (which is the current plan), then the actual parent will no longer be the event. Events are usually stack-allocated, thus temporary and intended to be movable. Change-Id: I24b648dcc046fc79d2401c781f1fda6cb00f47b0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add QPointerEvent::is[Press|Update|Release]Event accessorsShawn Rutledge2020-08-061-0/+12
| | | | | | | | | | QQuickPointerEvent had them, so despite how trivial they look, it's very convenient to keep using them in QQuickWindow rather than duplicating these kinds of checks in various places, and for multiple event types too. Change-Id: I32ad8110fd2361e69de50a679ddbdb2a2db7ecee Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add QEventPoint::pressTimestamp() and priv setPressTimestamp()Shawn Rutledge2020-08-061-1/+2
| | | | | | | | | | | | There was no good reason for QEventPoint::pressTimestamp() to be missing. The case for QEventPoint::timestamp() is a bit dubious because it's redundant with QInputEvent::timestamp(); but for now, we keep m_timestamp, in anticipation that Qt Quick may need to keep copies of eventpoints between events, thus they need to avoid depending on their shorter-lived parent events too much. Change-Id: Iec38acfdfaa2afb3dc77d5cd1b95baa8d301c0fd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix build with MSVC2019Mitch Curtis2020-07-311-0/+13
| | | | | | | | | | | | | | | | | The error was: src\virtualkeyboard\qvirtualkeyboardinputcontext_p.cpp(305): error C2678: binary '!=': no operator found which takes a left-hand operand of type 'QList<QInputMethodEvent::Attribute>' (or there is no acceptable conversion) This patch fixes the issue by manually defining an operator== for QInputMethodEvent::Attribute. Change-Id: Idb283cf7b6ff4388a38ea7780c3d5c1c5f77038d Fixes: QTBUG-85789 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QtGui: Rename all QEvent members according to the m_ conventionFriedemann Kleint2020-07-161-114/+114
| | | | | | | | | | | As they are protected, they need to be excluded from the Python bindings, which is best done by a pattern. Task-number: PYSIDE-1339 Task-number: PYSIDE-904 Change-Id: I667aa3b8e229e11b3b46635adfddbd62ce4747c1 Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Un-deprecate QMouseEvent::flags() and QGraphicsSceneMouseEvent::flags()Shawn Rutledge2020-07-151-1/+0
| | | | | | | | | | | | | | | | On one hand it looks like API clutter: a whole Qt namespace enum just to track whether an individual mouse click is about to geenerate a MouseButtonDblClick event. On the other hand, we should not remove it without replacing it somehow, so that users don't lose the workaround for QTBUG-25831 that it provides. That would be an invasive change because this flags property exists in QMouseEvent, QGraphicsSceneMouseEvent and in MouseArea { onClicked: doSomethingWith(mouse.flags) } Reverts a small part of 4e400369c08db251cd489fec1229398c224d02b4 Task-number: QTBUG-25831 Change-Id: I9a3b4f6cc6b858012186f10ed57689f8c0f5fd79 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QtGui: Clean up event headers, #3Friedemann Kleint2020-07-141-5/+0
| | | | | | | | - Remove unimplemented CT of QTabletEvent Task-number: QTBUG-72173 Change-Id: I22f88bc2962f2cf92cf33c9cba7081c0436affe6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QtGui: Clean up event headers, #2Friedemann Kleint2020-07-131-6/+0
| | | | | | | | | | - Remove unimplemented functions of QEventPoint - Remove forward declaration of devices Task-number: QTBUG-72173 Change-Id: I40e0451a6380ea7fbe58c49fe8fab1b432558c52 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-19 13:11:17 +0000