summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel/qevent.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Doc: Fix various documentation issuesTopi Reinio2021-04-161-0/+6
| | | | | | | | | | | | | - Document QIODeviceBase - Document QPointerEvent::points - Fix linking issues Task-number: QTBUG-90662 Task-number: QTBUG-92273 Change-Id: Ib123d5708953b22e01f95c82626b39a49fff95b2 Reviewed-by: Nico Vertriest <nico.vertriest@qt.io> (cherry picked from commit 00e10f62b55626097e94a2d70a9214c0062fbcd5) Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Output source in debug operator of QMouseEventFriedemann Kleint2020-11-251-0/+4
| | | | | | | | | Task-number: QTBUG-88678 Task-number: QTBUG-46412 Change-Id: If9282f5b845ef16ff7e7ce523f78e3b8adfbef90 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> (cherry picked from commit 45c623c42ac26eafff8e401709fa4c97ed9cd585) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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>
* Introduce QWindow::paintEvent with QPA plumbingTor Arne Vestbø2020-08-261-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | 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-1/+8
| | | | | | | | | | 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-12/+11
| | | | | | | | | | | | | | | | | | | | | | 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>
* Properly deprecate Qt::MidButton in favor of Qt::MiddleButtonEdward Welbourne2020-08-221-1/+1
| | | | | | | | | | | | MidButton had its // ### Qt 5: remove me upgraded to Qt 6 at 5.0; but it dates back to 4.7.0 Replace the many remaining uses of MidButton with MiddleButton in the process. Pick-to: 5.15 Change-Id: Idc1b1b1816673dfdb344d703d101febc823a76ff Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Introduce QEvent::isInputEventVolker Hilsheimer2020-08-171-1/+1
| | | | | | | | | | | | | This makes it easier to reliably maintain input-event related states in widgets, in particluar the state of keyboard modifiers. Instead of testing for all possible event types, code can just test the flag before safely static_cast'ing to QInputEvent to access the modifiers. Simplify the code in QAbstractItemView accordingly. Task-number: QTBUG-73829 Change-Id: Idc7c08e2f3f1e8844f5c6693c195153038ee6490 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add qt.pointer.grab logging in QEventPointShawn Rutledge2020-08-061-0/+27
| | | | | | | | | Add the logging category qt.pointer.grab, which generalizes the qt.quick.pointer.grab category in Qt 5 (and is almost always needed for troubleshooting Qt Quick pointer-handling bugs). Change-Id: I10b4f43aa60e8717d92ac43384d8fdeefd41d836 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add QPointerEvent::is[Press|Update|Release]Event accessorsShawn Rutledge2020-08-061-0/+50
| | | | | | | | | | 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>
* Remove InfoFlag from docsMichal Klocek2020-08-041-4/+7
| | | | | | | It seem to be a leftover after 4e400369. Change-Id: I1c12bfa70cb3716d5cd9d1306db23242b58f3096 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove an outdated and nonsensical comment in the docsGiuseppe D'Angelo2020-07-221-4/+0
| | | | | | | After the QVector->QList rename it made no sense. Change-Id: I4a422f48b1f5d42c1c4d402ea947a0f4098172b7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QtGui: Rename all QEvent members according to the m_ conventionFriedemann Kleint2020-07-161-48/+49
| | | | | | | | | | | 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>
* Set QEventPoint::state properly in QSinglePointEventShawn Rutledge2020-07-151-0/+6
| | | | | | | | | | | | | | | | | | State was Unknown by default, and that is OK in widgets so far, because widgets pay attention to the event type, not QEventPoint::state(). But Qt Quick cares about that, because QEventPoint turns into QQuickEventPoint, in which state() has long been important, due to the semi-unified handling of mouse and touch events. If it was not a button that caused the event, state is Updated (the mouse is hovering or dragging, or it's an enter event, wheel event etc.) If more buttons are now held than before, state is Pressed. If fewer buttons are now held than before, state is Released. Amends 4e400369c08db251cd489fec1229398c224d02b4 Change-Id: I926d268982449e46e7ca713c4a6ee2014c28c645 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Refactor pointer event hierarchyShawn Rutledge2020-07-101-627/+325
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 gui implementationJarek Kobus2020-07-071-4/+4
| | | | | | | Task-number: QTBUG-84469 Change-Id: I366e845249203d80d640355a7780ac2f91a762f1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Separate QPD::tabletDevice into priv tabletDevice and queryTabletDeviceShawn Rutledge2020-07-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There doesn't seem to be any reason users will need to query tablet devices by their IDs, because every event comes with a complete instance already, and we have QInputDevice::devices() to list them all. QPointingDevicePrivate::tabletDevice() can create a new instance if a matching one is not found (and complains about that); it's intended for use in QtGui, as a way to find the device if it was not part of the QWSI event. Now it sets the parent of those auto-created instances to QCoreApplication to avoid a memory leak. On the other hand, queryTabletDevice() is intended for use in platform plugins that need to check whether an instance exists; but they will take care of creating new instances themselves, and thus have more control over the parent and the details being stored. Now that the systemId can also be given, the search is more likely to have a unique result, on window systems that provide device IDs. Rename id() to systemId() to clarify that it's a system-specific unique device ID of some sort, not the same as the uniqueId that a stylus has. However it seems that in practice, this will often be 0; so clarify that if it's not unique, QInputDevicePrivate::fromId() and queryTabletDevice() may not always find the right instance. Clarify the function usage via comments. Change-Id: I82bb8d1c26eeaf06f07c290828aa17ec4a31646b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Introduce QInputDevice hierarchy; replace QTouchDeviceShawn Rutledge2020-06-161-121/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-15 03:59:28 +0000