path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Emit CancelGrabExclusive when one grabber is replaced by anotherShawn Rutledge2 days1-1/+2
| | | | | | | | | | | | | | Qt Quick Pointer Handlers depend on this behavior: QQuickPointerHandler::onGrabChanged() receives only the grabber that was losing the grab or the one that is receiving it, not both at the same time. UngrabExclusive means the original grabber simply relinquished the grab by setting the exclusive grabber to null. CancelGrabExclusive means the new grabber took over the grab that the old grabber had before. Task-number: QTBUG-86729 Change-Id: Iefca6fe91b11fcb03d2c6ac3598841c924facb22 Reviewed-by: Volker Hilsheimer <>
* Fix running with placeholder screen and high-dpi enabledEskil Abrahamsen Blomfeldt3 days1-0/+1
| | | | | | | | | | | | | | | | | After we started defaulting to high-dpi enabled, it was discovered that it does not work correctly with the placeholder screen. Since the placeholder screen has no physical size, and the default implementation of logicalDpi() divides by the physical size, we got a scale factor of NaN in the high-dpi code. The effect of this was that the nooutput test in Qt Wayland would fail, because it did not get the events it was expecting, since the window geometry was never set to a valid rect in the resize() call. Task-number: QTBUG-86698 Change-Id: I7ee68db9a13446b414502ae0f26fd214531c673a Reviewed-by: Tor Arne Vestbø <>
* Rename is[Begin|Update|End]Event, reimplement in QWheelEventShawn Rutledge3 days2-10/+38
| | | | | | | | | | | | | | 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ø <> Reviewed-by: Paul Wicking <> Reviewed-by: Volker Hilsheimer <>
* Deprecate implicit QPixmap conversion to QBitmapVolker Hilsheimer3 days2-2/+2
| | | | | | | | | | | | | | | | It is lossy, so should be requested explicitly, using a dedicated fromPixmap factory function. Deprecate the constructor and assignment operator, and make the constructor explicit. [ChangeLog][QtGui][QBitmap] Implicitly constructing and assigning to a QBitmap from a QPixmap has been deprecated, and the respective constructor has been made explicit. Use the fromPixmap factory function instead. Change-Id: I68ce85b26c901415137b664a1db687021d48bae0 Reviewed-by: Lars Knoll <>
* QPointingDevPriv::setExclusiveGrabber: emit grabChanged with point foundShawn Rutledge4 days1-1/+1
| | | | | | | | | | | | | | | | | | ...not with the given point. Since QEventPoint has a constructor that takes an id, it's possible to write something like pointerEvent->setExclusiveGrabber(pointId, object) which will construct a QEventPoint on-the-fly, containing only an id. (That was unintentional, but perhaps useful sometimes.) setExclusiveGrabber() looks up the persistent point, but if we emit the signal with the given point, it is missing the device. A handler connected to that signal might reasonably assume that the point is a complete instance; so we'd better emit the complete instance that we found. (OTOH if the given point was a detached instance, it might also be unexpected that the signal emits the persistent instance instead of the given instance.) Amends 2692237bb1b0c0f50b7cc5d920eb8ab065063d47 Change-Id: Iee16363dcb22c1dc07b0cc0a81930218e22fa19e Reviewed-by: Volker Hilsheimer <>
* Add more QPointerEvent functions needed in Qt QuickShawn Rutledge4 days6-0/+195
| | | | | Change-Id: I87a874477b89eb3f5951930f03e305d896a24c2e Reviewed-by: Volker Hilsheimer <>
* Mouse->touch synthesis: send touch event with mouse deviceShawn Rutledge4 days1-6/+1
| | | | | | | | | | | In 4e400369c08db251cd489fec1229398c224d02b4 we began to send synth-mouse events from the touch device, but in the opposite direction it was not consistent. Add autotests to prove that it's consistent both ways now. Change-Id: I7df2328fef224dc1529ca5d27411cd8a5a9c8df9 Reviewed-by: Volker Hilsheimer <>
* Calculate velocity in QMutEventPoint::setTimestamp() with Kalman filterShawn Rutledge4 days3-6/+67
| | | | | | | | | | | | | | 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 <>
* Track grab state in QPointingDevicePrivate::activePointsShawn Rutledge4 days10-256/+559
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <>
* Switch QSurfaceFormat::colorSpace to a QColorSpaceAllan Sandfeld Jensen6 days2-7/+34
| | | | | | | Allows more flexibility in the future. Change-Id: Idcf2d8ddaee268a7b5d55379ccb42dd9b3c33abf Reviewed-by: Tor Arne Vestbø <>
* Remove QPointerEvent::isPointAccepted() and setPointAccepted()Shawn Rutledge6 days1-2/+0
| | | | | | | | They are redundant, not in use, and got added without implementation in a81859a3c8d0f8b4367fc63988e1d653d34ed48a. Change-Id: Ifed1fbf97a8158c2801df09dac47bf1fc90795d4 Reviewed-by: Volker Hilsheimer <>
* Plumb application quit through platform pluginTor Arne Vestbø6 days4-0/+24
| | | | | | | | | | | | | | | | | | If we have a platform plugin we ask the platform to quit, and if not we fall back to the base implementation of QCoreApplication that sends Quit events directly. This allows the platform to involve the rest of the system in the process. The platform will then come back with a spontaneous quit via QWSI::handleApplicationTermination(), which will then send the corresponding Quit even from QGuiApplication like normal. Task-number: QTBUG-45262 Task-number: QTBUG-33235 Task-number: QTBUG-72013 Task-number: QTBUG-59782 Change-Id: I0000aaf7192e4b905933c5da0e53901c6c88f26a Reviewed-by: Lars Knoll <>
* Doc: Fix documentation issues for event and input device classesTopi Reinio10 days3-181/+287
| | | | | | | | | | | | | | * 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 <>
* Move grabbing API from QEventPoint to QPointerEventShawn Rutledge10 days2-64/+115
| | | | | | | | | | | | | | | | | | | | | | 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 <>
* Cleanup QAction::visible propertyAllan Sandfeld Jensen10 days4-17/+27
| | | | | | | | Gives it its own changed signal, and simplifies setting from group, while fixing an inconsistency in propagation. Change-Id: I22b243210260a8878144fa4b60204df46f847f37 Reviewed-by: Volker Hilsheimer <>
* Give QEventPoint a d-pointer after allShawn Rutledge11 days3-94/+222
| | | | | | | | | | 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 <>
* Refactor testlib touch functions into qtestsupport_gui and _widgetsShawn Rutledge13 days2-1/+121
| | | | | | | | | | | | | Because we removed public setters from QTouchEvent and QEventPoint in 4e400369c08db251cd489fec1229398c224d02b4 and now it's proposed to give QEventPoint a d-pointer again, the implementation of QTouchEventSequence needs to start using QMutableEventPoint: being a friend will no longer be enough, because the member variables won't be accessible in the future. But because we have separate test libs for Gui and Widgets, it needs to be further refactored into two classes. Change-Id: I0bfc0978fc4187348ac872e1330d95259d557b69 Reviewed-by: Volker Hilsheimer <>
* Remove deprecated API from QSurfaceFormatMarcel Krems13 days2-43/+0
| | | | | Change-Id: I8dacdaa18cea967a85e8835c2440ba53ee5df2e1 Reviewed-by: Tor Arne Vestbø <>
* Get rid of hasPendingEvents() and flush()Lars Knoll2020-09-061-1/+0
| | | | | | | They are unused. Change-Id: I77383f2be45551401ed9c2f88285511134cc8b0d Reviewed-by: Tor Arne Vestbø <>
* Tighten up QDialogButtonBox::ButtonLayout enumVolker Hilsheimer2020-09-032-11/+0
| | | | | | | | | | ... and the equivalent enum in QPlatformDialogHelper. No need to keep numerical values the same anymore. Remove ### Qt 6 comment. Change-Id: Ib369ea6ca2362f6ab0f71a3a6c90c4adaa7f11cd Reviewed-by: Tor Arne Vestbø <>
* Fix build without features.highdpiscalingTasuku Suzuki2020-09-041-2/+2
| | | | | | | Broken since 37d5aaa4b42f9c837f0d27edb9da2185971d02be Change-Id: Id741f23ccae4f619e6a389ee71b3e7fe0c599989 Reviewed-by: Friedemann Kleint <>
* Long live QKeyCombination!Giuseppe D'Angelo2020-09-039-33/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <>
* High-DPI: Remove legacy environment variablesTor Arne Vestbø2020-09-021-35/+2
| | | | | | | | | | | | | QT_DEVICE_PIXEL_RATIO is replaced by QT_SCALE_FACTOR, while QT_AUTO_SCREEN_SCALE_FACTOR is replaced by QT_ENABLE_HIGHDPI_SCALING. Since High-DPI is now always enabled, there's no reason to keep the code path for Also, based on the original commit message that introduced this code, the value of the property should have been true. Change-Id: Ib34b1deeab46c488c67c4d64f087599b4a54dc55 Reviewed-by: Morten Johan Sørvig <>
* Document native interfacesFriedemann Kleint2020-09-025-9/+17
| | | | | | | | | | | | | | As the private headers are not included by default in the precompiled header QDoc builds for QtGui, create a custom module header for the documentation build and pull in the required headers. Add dummy declarations for Windows-specific types for building docs on non-Windows platforms. Task-number: QTBUG-83252 Change-Id: I225ed08f68cf4f7c1f1d093424070b13ce36aa51 Reviewed-by: Qt CI Bot <> Reviewed-by: Tor Arne Vestbø <>
* Remove "fallback session management"Andreas Hartmetz2020-09-014-96/+1
| | | | | | | | | | | | | | With the Qt6 compatibility break, it can finally be removed. Closing windows (which might quit the application with quitOnLastWindowClosed() true, the default) acted contrary to the documentation of the commitDataRequest() signal, which could have been a hint. This removes the workaround API from the fix for QTBUG-49667 and also removes the problematic feature that it worked around. Change-Id: I672be58864ef062df7fb7f2a81658b92c4feedd2 Reviewed-by: Fabian Kosmale <>
* Doc: Compile droparea snippetPaul Wicking2020-09-011-1/+1
| | | | | | | | | | | droparea.h has been removed. Remove all code that depends on that header except the one snippet that is still used. Add minimal code to allow the snippet to be compiled. Done-with: Nico Vertriest <> Task-number: QTBUG-81486 Change-Id: I58c80d3527c82389ccff97567f4c75c33aec0f5e Reviewed-by: Topi Reiniö <>
* Deprecate and remove uses of AA_DisableHighDpiScalingTor Arne Vestbø2020-08-311-9/+1
| | | | | | Change-Id: Ibadce68775858c524b998aacad310905ba2c2e8e Reviewed-by: Volker Hilsheimer <> Reviewed-by: Morten Johan Sørvig <>
* Remove unused exported functions from QWSITor Arne Vestbø2020-08-311-17/+0
| | | | | Change-Id: If85231373bc0ec9a9259f628cd0c62a3a75b813b Reviewed-by: Friedemann Kleint <>
* Remove QWSIPrivate::EventType::FrameStrutMouseTor Arne Vestbø2020-08-311-1/+0
| | | | | Change-Id: I66eb05ae7ed58ff3375b756c29a96d5067251cc3 Reviewed-by: Friedemann Kleint <>
* High-DPI: Remove usage of Qt::AA_EnableHighDpiScalingTor Arne Vestbø2020-08-281-1/+1
| | | | | | | | This attribute is now on by default. Change-Id: I7c9d2e3445d204d3450758673048d514bc9c850c Reviewed-by: Morten Johan Sørvig <> Reviewed-by: Tor Arne Vestbø <>
* High-DPI: Don’t round scale factors in Qt 6Morten Johan Sørvig2020-08-281-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Set HighDpiScaleFactorRoundingPolicy to PassThough by default. This makes Qt track the system UI setting accurately, and is overall the least confusing option. Historically, Qt has rounded the scale factor (for example, Windows 175% -> DPR 2) due to faulty handling of fractional scale factors in Qt Widgets and with the native Windows style. Other areas of Qt such as Qt Quick have had few issues with fractional scale factors and support this well. Qt has never rounded the scale factor on the Android platform. Support for fractional scale factors in Qt Widgets and the windows style has improved, which makes changing the default for Qt 6 viable. Task-number: QTBUG-83068 Change-Id: I38b60f621f95be8ebb6cb84a07d3370fec19ab92 Reviewed-by: Tor Arne Vestbø <>
* High-DPI: Enable scaling by default in Qt 6Morten Johan Sørvig2020-08-281-7/+3
| | | | | | | | | | | | | | | Enable high-DPI support for all platforms which use QHighDpiScaling. This changes the default behavior of Qt applications on X11, Windows, and Android. Qt::AA_EnableHighDpiScaling is now effectively on by default, and Qt 6 applications do not have to set this application attribute. Opting out is possible by setting the Qt::AA_DisableHighDpiScaling attribute. Task-number: QTBUG-83068 Change-Id: Ia2bd3e6f490130afcacd3a951bc50dbb40a79d7f Reviewed-by: Tor Arne Vestbø <>
* Doc: Fix documentation warnings for Qt GUITopi Reinio2020-08-286-35/+26
| | | | | | | | | | | | * Drop deprecation warnings for now-dropped items * Use the 'qt6' define and a new \nothing doc macro to conditionally document items on Qt 6 * Add a custom module header for docs that pulls in also Vulkan headers * Add \internal command for internal classes/functions * Move QtGUI-related code snippets from widgets to gui docs Change-Id: Ieb386b96631a49568d09059906d307c45c01d93a Reviewed-by: Paul Wicking <>
* Add QOffScreenSurface platform API abstractionAssam Boudjelthia2020-08-276-72/+206
| | | | | | | | | | | | | | | | | | | | | This follows the work done in 6ff79478a44fce12ca18832a56db4a370a9ff417. The API is available by including qoffscreensurface.h, scoped in the QPlatformInterface namespace. The namespace exposes platform specific type-safe interfaces that provide: a) Factory functions for adopting native contexts, e.g. QAndroidPlatformOffscreenSurface::fromNative(ANativeWindow); b) Access to underlying native handles, e.g. surface->platformInterface<QAndroidPlatformOffscreenSurface>() ->nativeSurface() Fixes: QTBUG-85874 Change-Id: I29c459866e0355a52320d5d473e8b147e050acb3 Reviewed-by: Tor Arne Vestbø <>
* Move the QPalette::resolveMask into the privateVolker Hilsheimer2020-08-262-18/+32
| | | | | | | | | | | | | | | | | | | | | | | With 64bits, the mask is exhausted with the 21 colors x 3 color groups we have right now. In order to support accent colors, we need more palette entries. By moving the mask into the d-pointer, we can extend QPalette within the Qt 6 series, without breaking binary compatibility. The resolveMask/setResolveMask methods that take integers are documented as internals, so we can change those signatures after Qt 6.0 as well. As a side effect, setting the resolve mask on a QPalette detaches now. Setting a mask is in most cases done on the result of QPalette::resolve, which is usually detached already. And the QPalette default constructor will have to detach from the global application palette if that palette has any colors set explicitly. Task-number: QTBUG-82925 Change-Id: I1e70f1c4d0dd98303e353b91df5dba2b1fe8ba01 Reviewed-by: Tor Arne Vestbø <>
* Merge QOffscreenSurface constructor overloadsVolker Hilsheimer2020-08-262-16/+1
| | | | | | | Address ### Qt 6 comment Change-Id: I4ca9085266f9008b769bb164e6169439adadb12f Reviewed-by: Tor Arne Vestbø <>
* Introduce QWindow::paintEvent with QPA plumbingTor Arne Vestbø2020-08-2614-41/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <>
* Add note about use of receivedExpose member in QGuiApplicationTor Arne Vestbø2020-08-261-0/+6
| | | | | Change-Id: I221586a4fac394a9110d28905a898ab9688c1183 Reviewed-by: Volker Hilsheimer <>
* Rename QTabletEvent::m_zTilt to m_zShawn Rutledge2020-08-262-3/+3
| | | | | | | | This is a z coordinate unrelated to tilt, AFAIK. Amends ea2ae140e99bbd21515a99c5480e53129ef843c3 Change-Id: If165df3af290fbe7c2e5bfa94d578175debd53cd Reviewed-by: Tor Arne Vestbø <>
* Rename confusingly named QFont/QPalette::resolve overloadsVolker Hilsheimer2020-08-253-11/+13
| | | | | | | | | | | | | | | Having three methods with the same name doing different things is unnecessarily confusing, so follow the standard naming convention in Qt and call the getter of the resolve mask resolveMask, and the setter setResolveMask. These methods were all documented as internal. The publicly documented resolve() method that merges two fonts and palettes based on the respective masks remains as it is, even though 'merge' would perhaps be a better name. Change-Id: If90b1ad800834baccd1dbc38fc6b861540d6df6e Reviewed-by: Qt CI Bot <> Reviewed-by: Tor Arne Vestbø <>
* Introduce QEvent::isPointerEvent()Shawn Rutledge2020-08-252-1/+10
| | | | | | | | | | 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 <>
* Move QStateMachine from QtCore to QtScxmlKarsten Heimrich2020-08-243-1/+348
| | | | | | Task-number: QTBUG-80316 Change-Id: I2ee74110fd55e94d86321d3b3dc5bb8297424ed4 Reviewed-by: Maurice Kalinowski <>
* Remove QEventPoint::event() in favor of device()Shawn Rutledge2020-08-243-17/+16
| | | | | | | | | | | | | | | | | | | | | | 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 <>
* Add a metatype helper class for Qt CoreLars Knoll2020-08-241-2/+0
| | | | | | | | | This helps get better symmetry with the other modules, and to unify the code paths for both conversion and retrieving the interface for static types. Change-Id: Icbd20de2563f36e3de20d826323acd057734abfb Reviewed-by: Thiago Macieira <>
* Use QMetaTypeModuleHelper as the interface to do type conversionsLars Knoll2020-08-241-136/+62
| | | | | | | | | | | | | | Move the type conversions from QVariant::Helper to QMetaType. Only do this for Qt Gui in a first step. This makes it possible to completely remove the Handler struct in QVariant, and now allows QMetaType to also convert Gui types. Moving the conversion of Core types into QMetaType will require further work. Change-Id: I061f789deca1b595d92bb29227eb54b8e71a3ee3 Reviewed-by: Thiago Macieira <>
* Get rid of the additional bool * parameter to the internal convert methodLars Knoll2020-08-241-5/+2
| | | | | | | That parameter is duplicating the return value, get rid of it. Change-Id: I8d6ecee8aca90aecaf08e6d0072d83e9a08ce3d6 Reviewed-by: Thiago Macieira <>
* Remove some dead codeLars Knoll2020-08-241-15/+0
| | | | | | | | This code is now unused, as streaming operators are registered automatically. Change-Id: I0e48944c33a92cf1f2f158fb2dc0ca49256d7938 Reviewed-by: Thiago Macieira <>
* Get rid of the custom debug stream handling in QVariantLars Knoll2020-08-241-15/+1
| | | | | | | | Use the builtin support in QMetaType instead. Change-Id: Ifc0e88719a384aa7fb525652bada22b6f7ee1c45 Reviewed-by: Thiago Macieira <> Reviewed-by: Tor Arne Vestbø <>
* QPixelFormat: Fix warning about mixing different enumsMarcel Krems2020-08-231-14/+14
| | | | | | | | warning: C5054: operator '+': deprecated between enumerations of different types Pick-to: 5.15 Change-Id: If111b076914667fb149e62e051f52f408db9a338 Reviewed-by: Thiago Macieira <>
* qwsi: revert parts of 00ae1e6b7bf6efa5f5e57d37844e44d521604fb6Gatis Paeglis2020-08-232-24/+2
| | | | | | | | | | | | | | We actually do not need this "mode" in qwsi API. I think while writing the patch from 00ae1e6b7b I got confused by focusing on my test application. We can't know what the native event filter will filter out, therefore it makes sense that we unconditionally do filtering at qwsi level as well for user input vs other events in QWindowSystemInterface::sendWindowSystemEvents(). Pick-to: 5.15 Pick-to: 5.12 Change-Id: Idb23152a24bf3ba3b91804427a6e78f991969c29 Reviewed-by: Tor Arne Vestbø <>