summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qevent.h
Commit message (Collapse)AuthorAgeFilesLines
* Replace discouraged Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPEAndreas Buhr2020-12-041-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. Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> (cherry picked from commit 0440614af0bb08e373d8e3e40f90b6412c043d14) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Return subclass type from overrides of QEvent::cloneVolker Hilsheimer2020-11-241-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. Change-Id: I802f00a3c78e03047046986d0ed0a479b47573b8 Reviewed-by: Lars Knoll <lars.knoll@qt.io> (cherry picked from commit 146b37cdf376fb2fde85fa27326acfbeb2a024e3) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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>
* QtGui: Clean up event headersFriedemann Kleint2020-07-131-2/+0
| | | | | | | | | | - Remove unimplemented QSinglePointEvent() - Remove forward declaration of QTouchEventTouchPointPrivate - Update copyright and add comment to qevent_ph.h Task-number: QTBUG-72173 Change-Id: Ie64b6071f2611001dcd8e3deec2f5ed382bb2312 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Refactor pointer event hierarchyShawn Rutledge2020-07-101-232/+213
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some goals that have hopefully been achieved are: - make QPointerEvent and QEventPoint resemble their Qt Quick counterparts to such an extent that we can remove those wrappers and go back to delivering the original events in Qt Quick - make QEventPoint much smaller than QTouchEvent::TouchPoint, with no pimpl - remove most public setters - reduce the usage of complex constructors that take many arguments - don't repeat ourselves: move accessors and storage upwards rather than having redundant ones in subclasses - standardize the set of accessors in QPointerEvent - maintain source compatibility as much as possible: do not require modifying event-handling code in any QWidget subclass To avoid public setters we now introduce a few QMutable* subclasses. This is a bit like the Builder pattern except that it doesn't involve constructing a separate disposable object: the main event type can be cast to the mutable type at any time to enable modifications, iff the code is linked with gui-private. Therefore event classes can have less-"complete" constructors, because internal Qt code can use setters the same way it could use the ones in QTouchEvent before; and the event classes don't need many friends. Even some read-accessors can be kept private unless we are sure we want to expose them. Task-number: QTBUG-46266 Fixes: QTBUG-72173 Change-Id: I740e4e40165b7bc41223d38b200bbc2b403e07b6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use QList instead of QVector in guiJarek Kobus2020-06-291-5/+5
| | | | | | | | Applied to headers only. Source file to be changed separately. Task-number: QTBUG-84469 Change-Id: Ic08a899321eaffc46b8461aaee3dbaa4d2c727a9 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Introduce QInputDevice hierarchy; replace QTouchDeviceShawn Rutledge2020-06-161-63/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have seen during the Qt 5 series that QMouseEvent::source() does not provide enough information: if it is synthesized, it could have come from any device for which mouse events are synthesized, not only from a touchscreen. By providing in every QInputEvent as complete information about the actual source device as possible, we will enable very fine-tuned behavior in the object that handles each event. Further, we would like to support multiple keyboards, pointing devices, and named groups of devices that are known as "seats" in Wayland. In Qt 5, QPA plugins registered each touchscreen as it was discovered. Now we extend this pattern to all input devices. This new requirement can be implemented gradually; for now, if a QTWSI input event is received wtihout a device pointer, a default "core" device will be created on-the-fly, and a warning emitted. In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when multiple devices were in use simultaneously. Now that each event identifies the device it came from, this hack is no longer needed. A stub of the new QPointerEvent is added; it will be developed further in subsequent patches. [ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer to an instance of QInputDevice, or the subclass QPointingDevice in case of mouse, touch and tablet events. Each platform plugin is expected to create the device instances, register them, and provide valid pointers with all input events. If this is not done, warnings are emitted and default devices are created as necessary. When the device has accurate information, it provides the opportunity to fine-tune behavior depending on device type and capabilities: for example if a QMouseEvent is synthesized from a touchscreen, the recipient can see which touchscreen it came from. Each device also has a seatName to distinguish users on multi-user windowing systems. Touchpoint IDs are no longer unique on their own, but the combination of ID and device is. Fixes: QTBUG-46412 Fixes: QTBUG-72167 Task-number: QTBUG-69433 Task-number: QTBUG-52430 Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Prepare to harmonize pointer event accessor namesShawn Rutledge2020-06-081-61/+159
| | | | | | | | | | | | | | | | | | | | | | | ...by deprecating everything that doesn't conform to the naming scheme, and providing replacements. Continues what was started with QWheelEvent in 7d29807296cb7ccc7f3459e106d74f93a321c493. However QMouseEvent::pos() is left un-deprecated because it's so widely used. Also quit returning QPointF by const-ref from accessors. It's plenty small enough to return by value; we were never consistent about it anyway; and it's good to avoid some problems with returning a reference to a temporary in case the value is calculated in the accessor. [ChangeLog][QtGui][QPointerEvent] Mouse, touch and tablet events now have a standard set of QPointF accessors: position(), scenePosition() and globalPosition(). Existing accessors that return integer QPoints, and those with non-standard names, have been deprecated. You can use the clazy qevent-accessors check to update your code accordingly. Task-number: QTBUG-20885 Task-number: QTBUG-84775 Change-Id: I8e6f587da76d6d0bca6e965ce8ebc7e67b868011 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove obsolete storage, constructors and accessors in QEvent subclassesShawn Rutledge2020-05-121-84/+4
| | | | | Change-Id: I5c51244031ff40f1972106ad4fe27010c8be1193 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Change qHash() to work with size_t instead of uintLars Knoll2020-04-091-1/+1
| | | | | | | | | | | This is required, so that QHash and QSet can hold more than 2^32 items on 64 bit platforms. The actual hashing functions for strings are still 32bit, this will be changed in a follow-up commit. Change-Id: I4372125252486075ff3a0b45ecfa818359fe103b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-04-081-3/+13
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/opengl/doc/src/cube.qdoc src/corelib/global/qlibraryinfo.cpp src/corelib/text/qbytearray_p.h src/corelib/text/qlocale_data_p.h src/corelib/time/qhijricalendar_data_p.h src/corelib/time/qjalalicalendar_data_p.h src/corelib/time/qromancalendar_data_p.h src/network/ssl/qsslcertificate.h src/widgets/doc/src/graphicsview.qdoc src/widgets/widgets/qcombobox.cpp src/widgets/widgets/qcombobox.h tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp tests/benchmarks/corelib/io/qdiriterator/qdiriterator.pro tests/manual/diaglib/debugproxystyle.cpp tests/manual/diaglib/qwidgetdump.cpp tests/manual/diaglib/qwindowdump.cpp tests/manual/diaglib/textdump.cpp util/locale_database/cldr2qlocalexml.py util/locale_database/qlocalexml.py util/locale_database/qlocalexml2cpp.py Resolution of util/locale_database/ are based on: https://codereview.qt-project.org/c/qt/qtbase/+/294250 and src/corelib/{text,time}/*_data_p.h were then regenerated by running those scripts. Updated CMakeLists.txt in each of tests/auto/corelib/serialization/qcborstreamreader/ tests/auto/corelib/serialization/qcborvalue/ tests/auto/gui/kernel/ and generated new ones in each of tests/auto/gui/kernel/qaddpostroutine/ tests/auto/gui/kernel/qhighdpiscaling/ tests/libfuzzer/corelib/text/qregularexpression/optimize/ tests/libfuzzer/gui/painting/qcolorspace/fromiccprofile/ tests/libfuzzer/gui/text/qtextdocument/sethtml/ tests/libfuzzer/gui/text/qtextdocument/setmarkdown/ tests/libfuzzer/gui/text/qtextlayout/beginlayout/ by running util/cmake/pro2cmake.py on their changed .pro files. Changed target name in tests/auto/gui/kernel/qaction/qaction.pro tests/auto/gui/kernel/qaction/qactiongroup.pro tests/auto/gui/kernel/qshortcut/qshortcut.pro to ensure unique target names for CMake Changed tst_QComboBox::currentIndex to not test the currentIndexChanged(QString), as that one does not exist in Qt 6 anymore. Change-Id: I9a85705484855ae1dc874a81f49d27a50b0dcff7
| * Finish deprecating TouchPoint::rect, sceneRect and screenRect accessorsShawn Rutledge2020-03-301-3/+13
| | | | | | | | | | | | | | | | | | All 6 getters and setters were deprecated by doc comment \obsolete in 3c159957f863cf8d367a9261e7016e52cd0348c1 (Qt 5.9). Now we will generate compiler warnings too. Change-Id: I94c6da607fa5758072af1287c9286b6c52179cfb Reviewed-by: Frederik Gladhorn <gladhorn@kde.org>
* | Remove QTabletEvent::PointerType::XFreeEraserShawn Rutledge2020-04-021-2/+1
| | | | | | | | | | | | | | | | | | This is an artifact of pre-Qt 5 Wacom driver implementation, hasn't been in use during the Qt 5 series, but was kept for source compatibility with very old sources. Let's hope the usages are all gone by now. Change-Id: I39dc36699510ea5e51cacd369470264fd8a27b37 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | Remove QGuiAction again and split QAction implementation up insteadVolker Hilsheimer2020-03-291-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Duplicating the number of classes is a high price to pay to be able to have some QAction functionality behave differently, or be only available in widgets applications. Instead, declare the entire API in QtGui in QAction* classes, and delegate the implementation of QtWidgets specific functionality to the private. The creation of the private is then delegated to the Q(Gui)ApplicationPrivate instance through a virtual factory function. Change some public APIs that are primarily useful for specialized tools such as Designer to operate on QObject* rather than QWidget*. APIs that depend on QtWidgets types have been turned into inline template functions, so that they are instantiated only at the caller side, where we can expect the respective types to be fully defined. This way, we only need to forward declare a few classes in the header, and don't need to generate any additional code for e.g. language bindings. Change-Id: Id0b27f9187652ec531a2e8b1b9837e82dc81625c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | Initial cleanup of qevent.h for Qt6Allan Sandfeld Jensen2020-03-051-65/+15
| | | | | | | | | | | | | | | | | | | | | | | | Takes care of the first round of todos and deprecations for Qt6 in qevent. Not touching anything that might interfere with changing the class hierarchy as the file also suggest. Change-Id: If72d63d8932f1af588785bf77b34532358639a63 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-02-261-0/+11
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/network/bearermonitor/CMakeLists.txt examples/network/CMakeLists.txt src/corelib/tools/qlinkedlist.h src/sql/kernel/qsqldriver_p.h src/sql/kernel/qsqlresult_p.h src/widgets/kernel/qwidget.cpp src/widgets/kernel/qwidget_p.h tests/auto/network/socket/platformsocketengine/tst_platformsocketengine.cpp tests/auto/network/socket/qtcpsocket/tst_qtcpsocket.cpp tests/auto/tools/moc/allmocs_baseline_in.json Change-Id: I21a3c34570ae79ea9d30107fae71759d7eac17d9
| * Deprecate QTabletEvent::device() in favor of deviceType()Shawn Rutledge2020-02-171-1/+3
| | | | | | | | | | | | | | | | | | The idea is to reserve device() to return a pointer to a QInputDevice in the future, which is in sync with QQuickPointerEvent::device() and with QTouchEvent::device(). Change-Id: Ifda6e8aea72d5121955b31bdcbd91bf1bfa4cec4 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
| * Mark missing deprecation in QTabletEventAllan Sandfeld Jensen2020-02-141-0/+9
| | | | | | | | | | | | | | | | One constructor deprecated since 5.4, and two convenience variants of a method deprecated in 5.0. Change-Id: Ib1bba9ad529b3065461b86f80c9ec8dfc95f9ae1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * Merge remote-tracking branch 'origin/5.13' into 5.14Liang Qi2019-11-131-0/+7
| |\ | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/widgets/widgets/scribble/mainwindow.cpp This amends cb54c16584cf3be746a1a536c1e37cb3022a2f1b. Change-Id: Iaae60a893330524b2973917e23b31f9d51f8bd38
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-19 08:19:07 +0000