summaryrefslogtreecommitdiffstats
path: root/tests/auto/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Tests: Fix building with qmake on WindowsFriedemann Kleint2020-12-172-2/+2
| | | | | | | | Apparently some library definitions went overboard, link them directly. Pick-to: 6.0 Change-Id: I009737f7e3edff5619241b700a627dc4e25e6018 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Regenerate projects using pro2cmake one last timeAlexandru Croitor2020-12-104-22/+2
| | | | | | | | | And fix up some wrong qmake project files Pick-to: 6.0 Change-Id: I66cb82aeb9c1419a74df1a650fa78a511ade7443 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix weight when reading old serialized QFontsEskil Abrahamsen Blomfeldt2020-11-201-1/+1
| | | | | | | | | | | | | | | | | | The QFont::fromString() needs to differ between strings produced before and after Qt 6.0 when interpreting the weight value, since in older strings this will be the legacy scale. Luckily the number of tokens in the string can be used for this purpose, since many tokens were added in Qt 6.0. This broke KDE, where font settings are stored in QSettings and serialized using QFont::toString() from Qt 5. Fixes: QTBUG-88589 Pick-to: 6.0.0 6.0 Change-Id: I199737fed61917f8b9d8f86176ead29a89eb8e0c Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* Revert "Allow QWindowsPipe{Reader,Writer} to work with foreign event loops"Kai Koehne2020-11-201-41/+0
| | | | | | | | | | | | | | This reverts commit ee122077b09430da54ca09750589b37326a22d85. Reason for revert: This causes QProcess::readAll() to sometimes return nothing after the process has ended. Fixes: QTBUG-88624 Change-Id: I34fa27ae7fb38cc7c3a1e8eb2fdae2a5775584c2 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io> (cherry picked from commit 23100ee61e33680d20f934dcbc96b57e8da29bf9) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add tst_QHighDpi::mouseVelocity()Shawn Rutledge2020-11-201-0/+102
| | | | | | | | | | Ensure the values are reasonable regardless of screen DPI. Velocity is supposed to be in logical pixels / second. Task-number: QTBUG-88252 Task-number: QTBUG-88346 Change-Id: Ic209887f8ed0381c033a9ff04ae48b072c444df4 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Android: Ensure windows always have a geometry on creationPiotr Mikolajczyk2020-11-171-9/+0
| | | | | | | | | | | | | | | A QWindow created without an explicit geometry needs to pick up a default geometry in the platform plugin. If the window has a maximized of fullscreen window state, it will fill the entire available geometry of the parent window (or the screen if there's not parent window). Fixes: QTBUG-69159 Fixes: QTBUG-69156 Fixes: QTBUG-69154 Pick-to: 5.15 Change-Id: If8565d92a97bb4b3fa44757e68969d54d0bc7ebe Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Allow QWindowsPipe{Reader,Writer} to work with foreign event loopsAlex Trotsenko2020-11-171-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a foreign event loop that does not enter an alertable wait state is running (which is also the case when a native dialog window is modal), pipe handlers would freeze temporarily due to their APC callbacks not being invoked. We address this problem by moving the I/O callbacks to the Windows thread pool, and only posting completion events to the main loop from there. That makes the actual I/O completely independent from any main loop, while the signal delivery works also with foreign loops (because Qt event delivery uses Windows messages, which foreign loops typically handle correctly). As a nice side effect, performance (and in particular scalability) is improved. Several other approaches have been tried: 1) Using QWinEventNotifier was about a quarter slower and scaled much worse. Additionally, it also required a rather egregious hack to handle the (pathological) case of a single thread talking to both ends of a QLocalSocket synchronously. 2) Queuing APCs from the thread pool to the main thread and also posting wake-up events to its event loop, and handling I/O on the main thread; this performed roughly like this solution , but scaled half as well, and the separate wake-up path was still deemed hacky. 3) Only posting wake-up events to the main thread from the thread pool, and still handling I/O on the main thread; this still performed comparably to 2), and the pathological case was not handled at all. 4) Using this approach for reads and that of 3) for writes was slightly faster with big amounts of data, but scaled slightly worse, and the diverging implementations were deemed not desirable. Fixes: QTBUG-64443 Change-Id: I1cd87c07db39f3b46a2683ce236d7eb67b5be549 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* Android: exclude failing tests of tst_qhighdpiAssam Boudjelthia2020-11-161-0/+3
| | | | | | | | | Tests in tst_qhighdpi are crashing on Android. Task-number: QTBUG-88505 Task-number: QTBUG-87025 Change-Id: Ie1350e06fb30d90f20c550f91555f4023eee56b6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Stop copying events in testsVolker Hilsheimer2020-11-122-39/+29
| | | | | | | | It's unnecessary, and copying QEvents is a bad practice since it's a polymorphic class. Change-Id: Ieb6de106084f838c5e6c8a0643c54fd3c7f4a7a8 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* tests: Blacklist tst_qwindow failing test on WindowsAlexandru Croitor2020-11-071-1/+1
| | | | | | | | | Amends b13bad3ab0de96a3c6fe6dce4b9f35649f2f37d9 Task-number: QTBUG-35109 Task-number: QTBUG-88250 Change-Id: I0b37369bb7cfc58e6968ca20969725e2f4143200 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Introduce QEvent::isSinglePointEvent()Shawn Rutledge2020-11-072-0/+3
| | | | | | | | | | | | 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>
* tests: Blacklist failing tests on MinGWAlexandru Croitor2020-11-061-6/+4
| | | | | | | | | Also move redudant Android entries to already existing sections. Task-number: QTBUG-35109 Task-number: QTBUG-88250 Change-Id: I9d5eaa5a3f11b55566a7c74f84a972a0c272cfea Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Android: blacklist a list of failing tests for androidAssam Boudjelthia2020-11-043-0/+22
| | | | | | | | | | | | | | | | We want to re-enable Android tests in QTQAINFRA-3867. However, many tests are failing already preventing that from happening. QTBUG-87025 is currently keeping track (links) to all of those failing tests. The current proposal is to hide those failing tests, and enable Android test running in COIN for other tests. After, that try to fix them one by one, and at the same time we can make sure no more failing tests go unnoticed. Task-number: QTBUG-87025 Change-Id: Ic1fe9fdd167cbcfd99efce9a09c69c344a36bbe4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add QEventPoint::normalizedPosition() to replace normalizedPos()Shawn Rutledge2020-11-031-8/+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>
* Update tst_qguivariant to use QMetaTypeDavid Skoland2020-10-281-2/+2
| | | | | Change-Id: I4c789ecfc9f4613bd4820a8a6530249c51344a83 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Deprecate QVariant::TypeLars Knoll2020-10-231-2/+2
| | | | | | | | | It's been obsolete for a long time already. Make sure the compiler now warns about it and remove all remaining uses in qtbase. Change-Id: I0ff80311184dba52d2ba5f4e2fabe0d47fdc59d7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Rename the QMetaType::MovableType flag to RelocatableTypeLars Knoll2020-10-231-1/+1
| | | | | | | Keep this in sync with the changes we have done in QTypeInfo. Change-Id: Iaacb0f3cc5c46d3486084a1f6eca480a233d5e1a Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
* Fix a bunch of compiler warnings in event handling test casesVolker Hilsheimer2020-10-221-9/+12
| | | | | | | | Leave the normalizedPos warnings, there is no equivalent function. Change-Id: I50c72ab24b4855e36941aafdee30cdb0e94c1684 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* [Android] Make sure expose events are emitted after window resizePiotr Mikolajczyk2020-10-211-3/+0
| | | | | | | | | | | | Expose event would not be sent when window was resized Fixes: QTBUG-69155 Pick-to: 5.15 Change-Id: I81bf2d54f830a0dabf15398e1f25b55ff7ff4479 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Rami Potinkara <rami.potinkara@qt.io> Reviewed-by: Andy Shaw <andy.shaw@qt.io> Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
* QEvent copy constructor: copy the type flags tooShawn Rutledge2020-10-211-0/+9
| | | | | | | | | | | | | Failure to copy m_inputEvent and m_pointerEvent actually left them uninitialized, and resulted in random behavior in Qt Quick when Flickable clones a pointer event for later replay. Remove the comment about copying events being a "bad idea" in Qt 4, while we're at it. Copying became more common in Qt 5, and we probably won't be able to stop doing it now. Change-Id: I40b6ba5ad696e7aaafbeefbca86eca00cab40616 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge existing tst_qhighdpiscaling into tst_qhgihdpiMorten Johan Sørvig2020-10-205-105/+23
| | | | | | | | | Move the factor() test, drop scale() which should be covered already. Change-Id: Id2079536a91c7e9f7199960bdf6b33489d0a6670 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Add high-dpi auto testMorten Johan Sørvig2020-10-205-0/+455
| | | | | | | | | | | | | | | | | | Use the new screen config feature of the offscreen platform plugin to run tests on virtual screen setup. This has the benefit that we can auto-test the QHighDpiScaling implementation (as well as its usage in QtGui) on any platform with a fixed mock screen setup which does not rely on physical screen configuration. Test the following configurations: - three screens: 96 DPI. (reference) - three screens: 192 DPI - three screens: mixed (high) DPI Change-Id: I2fac889d896cf30ab2a79c306cee22177ad8f4ac Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Fix compile warnings from ignored return valueVolker Hilsheimer2020-10-171-2/+2
| | | | | | | | The return value can be ignored here, so make intention clear. Change-Id: I116869c47039b159db96f133b5850a2215873c2f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Rename the new platform APIs from QPlatformInterface to QNativeInterfaceTor Arne Vestbø2020-10-071-2/+2
| | | | | | | | | | | | We were already using the 'native' nomenclature when referring to these kinds of APIs, e.g. when talking about native handles, or the existing QPlatformNativeInterface on a QPA level. Using 'native' for the user facing APIs also distinguishes them from the 'platform' backend layer in QPA and elsewhere. Change-Id: I0f3273265904f0f19c0b6d62471f8820d3c3232e Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* End touch->mouse synthesis when the chosen touchpoint is releasedShawn Rutledge2020-10-021-0/+24
| | | | | | | | | | | | | | | | During delivery of a TouchBegin event, if no widget accepts it, we begin treating the first touchpoint as a synth-mouse, as before. If a second touchpoint is pressed or released in any order, it's irrelevant: the fake mouse button is released as soon as the first touchpoint is released. This fixes the bug that such a scenario caused the mouse release not to be sent, so that a widget could get "stuck" in pressed state. Done-with: Tang Haixiang <tanghaixiang@uniontech.com> Fixes: QTBUG-86253 Pick-to: 5.15 Change-Id: I7fbbe120539d8ded8ef5e7cf712a27bd69391e02 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* tst_qwindow: verify isBeginEvent(), isUpdateEvent() and isEndEvent()Shawn Rutledge2020-09-301-8/+25
| | | | | | | | | | | | | | | | | | It also demonstrated that the tests were out of sync with reality: since a97759a336c597327cb82eebc9f45c793aec32c9 QMouseEvent::button() and QWindowSystemInterfacePrivate::MouseEvent::button should be the button that changes state of course; but when a button is pressed, we are reacting to it after the fact, so QMouseEvent::buttons() and QWindowSystemInterfacePrivate::MouseEvent::buttons should include the new button that was just pressed. Likewise when a button was released, we send the event with buttons _omitting_ the button that was just released. Amends 147a8bc4c86dd7c818acd2614ee67cd7098cfa5e and 6d6ed64d6ca27c1b5fec305e6ed9b923b5bb1037 Change-Id: I670289019fcfa7de685ca38799804772dc0f1c8f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Revert "Blacklist tst_QWindow::exposeEventOnShrink_QTBUG54040"Liang Qi2020-09-301-1/+0
| | | | | | | | | | | | This reverts commit b1ef104866f78ae5bbc1214ae524bad4120ef0e2. This test is BPASS on openSUSE_42_3 for 5.12 and PASS on openSUSE_15_1 for 5.15. Pick-to: 5.15 Pick-to: 5.12 Change-Id: Ia1d81ed38491c27c01f270623c5082663f4da699 Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
* Fix compiler warnings from QKeyCombinationLars Knoll2020-09-282-35/+35
| | | | | | | | Change lots of code to avoid the deprecated operator+() or implicit casts to int. Change-Id: I0c343cd5b28603afdf1214eefb85e928313345e2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* CMake: Regenerate projects to use new qt_internal_ APIAlexandru Croitor2020-09-2342-68/+55
| | | | | | | | | | | Modify special case locations to use the new API as well. Clean up some stale .prev files that are not needed anymore. Clean up some project files that are not used anymore. Task-number: QTBUG-86815 Change-Id: I9947da921f98686023c6bb053dfcc101851276b5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Regenerate projectsAlexandru Croitor2020-09-221-1/+1
| | | | | | | | | Clean up the state of the projects, before changing the internal CMake API function names. Task-number: QTBUG-86815 Change-Id: I90f1b21b8ae4439a4a293872c3bb728dab44a50d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix failing tests on macOS developer buildsAlexandru Croitor2020-09-222-0/+14
| | | | | | | | | | | | | | | | | | tst_qguiapplication was missing an Info.plist file. We can't directly reference the tst_qcoreapplication Info.plist file like the qmake project does, because that breaks ninja (says multiple rules create the same output file), so use a copy instead. Blacklist the qpluginloader loadMachO test when doing CMake builds. The qmake projects use multiple custom rules to build the macho plugins, which need to be ported to CMake. Task-number: QTBUG-86053 Task-number: QTBUG-86792 Change-Id: Iaff2b2d5e9e84a457b4f2ffc011a580388498f00 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Cleanup API of QMimeDataLars Knoll2020-09-211-1/+1
| | | | | | | | | | | | | Do not use QVariant::Type anymore, instead use QMetaType For some reason, this pushed the qvariant autotest over the limit where MSVC requires the /bigobj flag, so add that one. [ChangeLog][QtCore][QMimeData] The signature of the virtual retrieveData() function has changed and now takes a QMetaType instead of a QVariant::Type. Change-Id: Ib46773bd731ee2177b1ef74d8162d744be7017ef Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Rename is[Begin|Update|End]Event, reimplement in QWheelEventShawn Rutledge2020-09-172-14/+14
| | | | | | | | | | | | | | 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>
* Mouse->touch synthesis: send touch event with mouse deviceShawn Rutledge2020-09-161-1/+19
| | | | | | | | | | | 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 <volker.hilsheimer@qt.io>
* Calculate velocity in QMutEventPoint::setTimestamp() with Kalman filterShawn Rutledge2020-09-162-1/+101
| | | | | | | | | | | | | | 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-164-37/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix compiler warnings about missing overridesLars Knoll2020-09-131-1/+1
| | | | | Change-Id: I52bf9fe45607f4a99cafa441bd78dfe5f7adb0e1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove most compiler warnings about missing overridesLars Knoll2020-09-118-17/+18
| | | | | | | | | | | | Remove around 1000 compiler warnings about missing overrides in our auto tests. This significantly reduce the compiler warning noise in our auto tests, so that one can actually better see the real problems inbetween. Change-Id: Id0c04dba43fcaf55d8cd2b5c6697358857c31bf9 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Port from devicePixelRatioF() to devicePixelRatio()Morten Johan Sørvig2020-09-101-1/+1
| | | | | | | This ports all of QtBase. Change-Id: If6712da44d7749b97b74f4614a04fac360f69d9e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Cleanup QAction::visible propertyAllan Sandfeld Jensen2020-09-101-0/+3
| | | | | | | | Gives it its own changed signal, and simplifies setting from group, while fixing an inconsistency in propagation. Change-Id: I22b243210260a8878144fa4b60204df46f847f37 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Give QEventPoint a d-pointer after allShawn Rutledge2020-09-101-0/+2
| | | | | | | | | | 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>
* Refactor testlib touch functions into qtestsupport_gui and _widgetsShawn Rutledge2020-09-081-5/+5
| | | | | | | | | | | | | 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 <volker.hilsheimer@qt.io>
* tst_qshortcut (x2): use op | instead of op + to combine keysGiuseppe D'Angelo2020-09-071-1/+1
| | | | | | | | | | | | | | Following the introduction of QKeyCombination, reduce the number of warnings raised by the test. Drive-by, remove some pointless math like Qt::SHIFT+0, which does not make any sense and would actually fail to compile (shortly). Refactoring the test to fully use QKeyCombination (instead of ints) is left as a future exercise; some QKeyCombination->int warnings are still around. Change-Id: If825bc4c369986623447927bb11493c4f58b544f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Long live QKeyCombination!Giuseppe D'Angelo2020-09-031-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Deprecate and remove uses of AA_DisableHighDpiScalingTor Arne Vestbø2020-08-311-1/+2
| | | | | | Change-Id: Ibadce68775858c524b998aacad310905ba2c2e8e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Fix tst_QHighDpiScaling::scaleTor Arne Vestbø2020-08-281-0/+2
| | | | | | | | | | Without an override for logicalDpi() the base class implementation would use the geometry of the screen to figure out the DPI, and end up with ~100, which combined with a 96DPI base logical DPI would give a wrong scale factor. Change-Id: I68aecce44d2ee672c7b707dfe5444af8f551e961 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Use OpenType font weightsJonas Karlsson2020-08-281-2/+2
| | | | | | | Task-number: QTBUG-42248 Change-Id: Icdb301b27d6699c2b842c4563fbef9df73c23cbc Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* Introduce QWindow::paintEvent with QPA plumbingTor Arne Vestbø2020-08-263-1/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Cleanup QTypeInfoLars Knoll2020-08-261-1/+1
| | | | | | | | | | | | | | | Remove QTypeInfo::isStatic, as that's not used anymore in Qt 6. Also remove sizeOf, it's unused, and we have QMetaType for that if required. Remove all typeinfo declaractions for trivial types, as the default template covers them correctly nowadays. Finally set up a better default for isPointer, and do some smaller cleanups all over the place. Change-Id: I6758ed37dfc701feaaf0ff105cc95e32da9f9c33 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 16:41:53 +0000