summaryrefslogtreecommitdiffstats
path: root/tests/auto/widgets/kernel/qapplication/tst_qapplication.cpp
Commit message (Collapse)AuthorAgeFilesLines
* tests: skip tst_QApplication::abortQuitOnShow() on WaylandLiang Qi2024-03-221-0/+3
| | | | | | | | The test started to "crash" since 576c9160b12ac5efc76d06ca7ccc856aad2b051a. Task-number: QTBUG-123172 Change-Id: I16c78f517f718510aa22a2e24ed3d502edae52e5 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Android: Make timeout in tst_QApplication::abortQuitOnShow() longerTinja Paavoseppä2024-02-271-1/+7
| | | | | | | | | | | | | | Since the Android emulator on CI is running without hardware accelerated graphics, showing the widget can take almost the same time as the timeout for exiting the app with the "wrong" exit code 1. If running on Android, increase the timeout to 1000 ms to avoid flaky failures. Un-blacklist tst_QApplication::abortQuitOnShow() since the random failures are taken care of by this patch. Task-number: QTBUG-122693 Pick-to: 6.7 Change-Id: Id52ae15b3ab2dbdaf4924b675276dfe3a4168585 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Try to stabilize tst_QApplication::abortQuitOnShowVolker Hilsheimer2024-02-221-1/+15
| | | | | | | | | | | The test has been very flaky recently. A zero timer might be processed before the window became visible, so only start closing once the window has been shown. Pick-to: 6.7 6.6 Change-Id: If7983723bb8abd2f3495fb21114c517289ebe8d9 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Change license for tests filesLucie Gérard2024-02-041-1/+1
| | | | | | | | | | | | According to QUIP-18 [1], all tests file should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8 Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
* Debounce QDeferredDeleteEvents in QObject::deleteLater()Tor Arne Vestbø2023-12-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to look through the event queue in QCoreApplication::postEvent, and if we found an existing DeferredDelete event for the receiver we would compress the two events into one. This was changed in 99b89d30fa5484c5d1f3cbda828648c28af4fb7d, as the logic was causing O(n^2) for deleteLater, by using one of the bits in QObjectData to track whether the object had already been deleted. But it kept the logic for tracking this in QCoreApplication::postEvent, and QCoreApplication::compressEvent would still do the work of deleting the additional QDeferredDeleteEvents. To avoid the unnecessary heap allocation of the QDeferredDeleteEvents we can move the debouncing/compression to QObject::deleteLater(). We use the same mutex as in QCoreApplication::postEvent to guard concurrent access to deleteLaterCalled. A note has been added about the (preexisting) issue that the mutex is not sufficient to prevent data races, as the deleteLaterCalled flag is part of a bit-field, and we're not guarding any of our other accesses to other bits. As QDeferredDeleteEvents is private API, we can rely on no-one else posting it than QObject::deleteLater(), which should be the case now that tst_QApplication::sendPostedEvents() was fixed. The documentation has been clarified as well. It's safe to call deleteLater() more than once, but that's not _because_ other pending events for the object are cleared. The latter behavior is normal ~QObject() behavior. The documentation was probably written at a point we didn't do any event compression at all for QDeferredDeleteEvents. Task-number: QTBUG-120124 Task-number: QTBUG-119918 Change-Id: I2a733095b7cb066ba494b1335aa40200c749cb0c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Unskip tst_QApplication::testDeleteLater() on macOSTor Arne Vestbø2023-12-041-3/+0
| | | | | | | | | It passes locally, let's give it a shot in the CI. Fixes: QTBUG-24318 Change-Id: I7df735bdc7963c9c1a8ad8befdc0642f796c32a1 Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Add QEXPECT_FAIL to tst_QApplication::sendEventsOnProcessEventsTero Heikkinen2023-08-101-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Test sendEventsOnProcessEvents has been noticed to fail when qgtk3 (Glib) is loaded - Should be fixed in QTBUG-87137 Moving test from blacklist to use QEXPECT_FAIL as it's more recommended until test is fixed in the relevant configurations. QEXPECT_FAIL is selected to use as original investigator reported also some cases when glib is working. Therefore this approach is giving us more insight for further investigation is it always failing with glib or not. It was also reported linkage to zeroTimer test QTBUG-84291, but not sure why removing that has affected to this one. Update to QEXPECT_FAIL documentation to tell in first place that XPASS is not only marking it as XPASS but also failing the test. Same is mentioned in different location but it needs more searching or testing how it works in real test. Task-number: QTBUG-115155 Change-Id: I7fb4ef28dba8adb7009be528f88fc758a12e9006 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Fix sending deferred delete events when posted before outermost loopMikolaj Boc2023-06-091-0/+5
| | | | | | | | | | | | | | | | | | | | | QDeferredDeleteEvent has the loopLevel field, which is a sum of scope and loop levels found at posting. In sendPostedEvents however, it is impossible to only use this information to find delete events posted before the outermost loop (which should be handled by any loop) based solely on this information, as the scope level essentialy removes the information on loop level. Break the loopLevel in two, storing both loop and scope levels in QDeferredDeleteEvent, so that we can check whether an event was posted before the outermost event loop (for which we need to compare only the loop level). QDeferredDeleteEvent was also made private as it should - it is an implementation detail that wasn't hidden properly. Change-Id: I0a607a0bd3a2deb5024acad67f740dbf4338574c Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* Don't use native dialogs for tst_QApplication::closeAllWindows()Tor Arne Vestbø2023-01-021-0/+1
| | | | | | | | | | | | | The test shows an application modal QMessageBox, but assumes that doing so will be non-blocking, which for macOS is not the case (yet). Instead of making the dialog window-modal, which would potentially affect the logic of the test, we disable native dialogs. This should be fine, as the purpose of the test is to test the is_closing logic of closeAllWindows, which lives on a layer above the native dialogs. Pick-to: 6.5 Change-Id: I6d627984a6ca452b876f34404b669fce41a00851 Reviewed-by: Doris Verria <doris.verria@qt.io>
* Port from container::count() and length() to size() - V5Marc Mutz2022-11-031-60/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to handle typedefs and accesses through pointers, too: const std::string o = "object"; auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); }; auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) { auto exprOfDeclaredType = [&](auto decl) { return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o); }; return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes)))); }; auto renameMethod = [&] (ArrayRef<StringRef> classes, StringRef from, StringRef to) { return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)), callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))), changeTo(cat(access(o, cat(to)), "()")), cat("use '", to, "' instead of '", from, "'")); }; renameMethod(<classes>, "count", "size"); renameMethod(<classes>, "length", "size"); except that the on() matcher has been replaced by one that doesn't ignoreParens(). a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'. Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache, to avoid porting calls that explicitly test count(). Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Proper clearing of WinRT factory cacheAndreas Buhr2022-10-311-0/+15
| | | | | | | | | | | | | | | | | | | If we use winrt's factories we have to make sure to to clear the factory cache when one of our dlls is unloaded or we will run into dangling factory entries which might result in crashes. So we have to make sure that winrt::clear_factory_cache is called on every dll unload. In order not to increase compile times and dependencies too much qfactorycacheregistration_p.h needs to be included in Qt code whenever we use winrt's factory cache. A rule of thumb being: Include qfactorycacheregistration_p.h whenever including winrt/base.h. Other Qt modules which use winrt's factories need to be updated too. Fixes: QTBUG-103611 Pick-to: 6.2 6.4 Change-Id: I7ab24e4b18bffaca653c5b7f56a66ce99212e339 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Port from qAsConst() to std::as_const()Marc Mutz2022-10-111-4/+4
| | | | | | | | | | | | | | | | We've been requiring C++17 since Qt 6.0, and our qAsConst use finally starts to bother us (QTBUG-99313), so time to port away from it now. Since qAsConst has exactly the same semantics as std::as_const (down to rvalue treatment, constexpr'ness and noexcept'ness), there's really nothing more to it than a global search-and-replace, with manual unstaging of the actual definition and documentation in dist/, src/corelib/doc/ and src/corelib/global/. Task-number: QTBUG-99313 Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* tests: skip tst_QApplication::activateDeactivateEvent() on WaylandLiang Qi2022-10-071-0/+3
| | | | | | | Task-number: QTBUG-107153 Pick-to: 6.4 6.2 Change-Id: I69bd4a0d4217b5e4c2cbee8b25c5bd69509e3329 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* Port from container.count()/length() to size()Marc Mutz2022-10-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is semantic patch using ClangTidyTransformator: auto QtContainerClass = expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o) makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container'. <classes> are: // sequential: "QByteArray", "QList", "QQueue", "QStack", "QString", "QVarLengthArray", "QVector", // associative: "QHash", "QMultiHash", "QMap", "QMultiMap", "QSet", // Qt has no QMultiSet Change-Id: Ibe8837be96e8d30d1846881ecd65180c1bc459af Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Deprecate QApplication::setActiveWindow() and mark as internalTor Arne Vestbø2022-08-271-9/+9
| | | | | | | | | | | | | | The function is used the internal window activation machinery and should not be called by user code. Many tests still use this function, and should be ported over to QWidget::activateWindow(). For now they are using the private helper in QApplicationPrivate, so that we can progress with the public API deprecation. Change-Id: I29f1575acf9efdcbae4c005ee9b2eb1bb0c8e5b5 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* qputenv: port to QByteArrayViewMarc Mutz2022-08-061-1/+1
| | | | | | | | | | | | | | | | | | | | The vast majority of in-tree users pass simple and short C string literals as the value. By porting to QByteArrayView, we document that we'll accept non-NUL-terminated data, and do the NUL-termination internally, using SSO'ed std::string, saving memory allocations in the common case of short strings. I didn't bother to check which direction std::string takes for nullptrs these days (there was a change accepted in that area for C++20 or 23), so play it safe and protect against them. Follow-up to Task-number: QTBUG-105302 Change-Id: I2369acc62f1d5cbc26135396cfe0602d8c75300c Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QGuiApplication: do not emit deprecated signalsIvan Solovev2022-07-211-0/+7
| | | | | | | | | | | | | | ... when QT_DISABLE_DEPRECATED_BEFORE is past the deprecation version. This commit actually stops using the deprecated signals when we build Qt with QT_DISABLE_DEPRECATED_BEFORE >= 0x060000. Otherwise we will get a compilation error because the signals will be removed. Task-number: QTBUG-104857 Pick-to: 6.4 6.3 6.2 Change-Id: Ie513ecc9451bf2d88f80857cf19f3d2b4958d022 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-27/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Add override keyword to avoid warning from compilerOliver Eftevaag2022-05-131-1/+1
| | | | | | | | | A class that reimplements a virtual function isn't using the override keyword, which generates a warning during compilation. Pick-to: 6.3 Change-Id: Ic39ea24993e031f95ac9e61c3285d3be05fe6c34 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QApplication: deliver activation events for non-widget windowsRichard Moe Gustavsen2022-04-211-0/+48
| | | | | | | | | | | | | | | | | | Problem: if you create a hybrid Widgets and Quick Controls application, you would need to use QApplication rather than QGuiApplication. But in that case, the QQuickWindows would never receive window activation events from QApplication. And this causes problems for controls, since, for example, the palettes in use there will never update upon activation changes, and instead sometimes get stuck as e.g QPalette::Inactive after application startup. This patch will make sure that we send out activation events also for QWindows that are not QWidgetWindows. Pick-to: 6.3 6.2 Change-Id: I649f5c653081c0c5249f4faf28a7de2c92f17421 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QProcess/Unix: ensure we don't accidentally execute something from CWDThiago Macieira2022-02-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unless "." (or the empty string) is in $PATH, we're not supposed to find executables in the current directory. This is how the Unix shells behave and we match their behavior. It's also the behavior Qt had prior to 5.9 (commit 28666d167aa8e602c0bea25ebc4d51b55005db13). On Windows, searching the current directory is the norm, so we keep that behavior. This commit does not add an explicit check for an empty return from QStandardPaths::findExecutable(). Instead, we allow that empty string to go all the way to execve(2), which will fail with ENOENT. We could catch it early, before fork(2), but why add code for the error case? See https://kde.org/info/security/advisory-20220131-1.txt [ChangeLog][Important Behavior Changes] When passed a simple program name with no slashes, QProcess on Unix systems will now only search the current directory if "." is one of the entries in the PATH environment variable. This bug fix restores the behavior QProcess had before Qt 5.9. If launching an executable in the directory set by setWorkingDirectory() or inherited from the parent is intended, pass a program name starting with "./". For more information and best practices about finding an executable, see QProcess' documentation. Pick-to: 5.15 6.2 6.3 Change-Id: I54f205f6b7314351b078fffd16cf7013c97ee9fb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Deprecate QContextMenuEvent and QMouseEvent ctors without globalPosShawn Rutledge2022-02-051-1/+1
| | | | | | | | | | | | | As with QHoverEvent, it's better to require globalPos rather than "initialized to QCursor::pos(), which may not be appropriate" as the docs have pointed out for many years now. This removes the remaining calls to QCursor::pos() in event constructors. Task-number: QTBUG-52430 Task-number: QTBUG-69433 Task-number: QTBUG-100324 Change-Id: I076dae56f37abaad7085cc95dddee453a80a45f3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix references to QGuiApplication::lastWindowClosedTor Arne Vestbø2021-10-131-2/+2
| | | | | | | | | The signal is emitted from QGuiApplication these days. Pick-to: 6.2 Change-Id: I7423cd4808e8df86960f225fd6e4a12a1a4f11f3 Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* tst_qapplication: Prevent desktopaware test from deactivating main testTor Arne Vestbø2021-02-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Applications on macOS are automatically activated (put into the foreground), when launched from the Finder, or via 'open' on the command line. But when launched from the terminal, e.g. foo.app/Contents/MacOS/foo, the application will launch in the background (inactive). In Qt we override this behavior, activating the app even when launched from the terminal, as a convenience, as long as the application is a GUI application. Unfortunately this means that when tst_qapplication launches a subprocess that is a GUI app, it will steal activation from tst_qapplication, which in turn will break tests that later try to activate a window and check that the window is then active. The window will not be active until the application is active. We can work around it by preventing Qt from activating the application, but ideally we'd find a better solution to this, as we don't want to sprinkle overrides all over our tests. Fixes: QTBUG-90699 Pick-to: 6.1 6.0 5.15 Change-Id: If53a86548002b739df0c0a7153d6244924a4a205 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Fix setting active window as application's focus widgetSona Kurazyan2021-01-151-0/+40
| | | | | | | | | | | | | | | | | | | | | | When setting the application's focus widget we search for the next child widget that can hold the focus and call its setFocus() method, which also updates focus widgets of all its parent wigets. In case if the focus widget is the active window itself, we only set it as the application's focus widget, but we don't update the focus widget of the active window itself. Because of this the focusWidget() method always results nullptr for the active window. This prevents from setting the focus back to active window after the focus has changed (for example after a context menu is closed, as in the bugreport). Transfer the focus to active window by calling the setFocus() method, as it is done in case of transferring the focus to any other widget. Pick-to: 6.0 5.15 Fixes: QTBUG-85846 Change-Id: I91ebf182fd5bb7d451a1186e2f3e38c8d48acc4e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix QApplication::font returns the font unstable according to the objectChunLin Wang2021-01-151-0/+42
| | | | | | | | | If a default font was not registered for the widget's class, it returns the default font of its nearest registered superclass. Fixes: QTBUG-89910 Pick-to: 5.15 6.0 Change-Id: I6e6b2c6a0044462f84db9f76a03be0c6cfaaae8e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove the qmake project filesJoerg Bornemann2021-01-071-2/+2
| | | | | | | | | | | | | | | | Remove the qmake project files for most of Qt. Leave the qmake project files for examples, because we still test those in the CI to ensure qmake does not regress. Also leave the qmake project files for utils and other minor parts that lack CMake project files. Task-number: QTBUG-88742 Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Replace QtTest headers with QTestDavid Skoland2020-12-221-1/+6
| | | | | | | | | | | Complete search and replace of QtTest and QtTest/QtTest with QTest, as QtTest includes the whole module. Replace all such instances with correct header includes. See Jira task for more discussion. Fixes: QTBUG-88831 Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44 Pick-to: 6.0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Get rid of all instance usage of QFontDatabaseVolker Hilsheimer2020-11-031-6/+3
| | | | | | | | All QFontDatabase APIs are static, use them accordingly. Task-number: QTBUG-88114 Change-Id: I0e4a7508646037e6e2812611262eed8b6d7ad3de Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* CMake: Fix tst_qapplication to respect blacklists in CMake buildsAlexandru Croitor2020-10-301-0/+1
| | | | | | | | | | | CMake builds are special and need to know the path to the source dir. This is handled automatically by QTEST_MAIN, but tst_qapplication doesn't use QTEST_MAIN. Thus we need to call QTEST_SET_MAIN_SOURCE_PATH manually. Task-number: QTBUG-87137 Change-Id: Ib2c461f0da0a3d9a2f571f37476b750a606065f7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Swallow some runtime warnings from tst_qapplicationVolker Hilsheimer2020-10-181-0/+2
| | | | | Change-Id: I226c3b55a1666eb3ccd369a3307919d4c72a2600 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix compile warning from testing deprecated signalVolker Hilsheimer2020-10-181-7/+46
| | | | | | | Silence the warning, and test event delivery in addition. Change-Id: I59c49a2ac70ecd32429116b76643700a7ad5ce3e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Get rid of all usage of QApplication:desktopVolker Hilsheimer2020-10-141-1/+0
| | | | | | | | Use QScreen APIs instead. Change-Id: Ie99af94fe4292223dbb165b3f5c1b74e8fe0498b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Rename QLibraryInfo::location() to path()Lars Knoll2020-09-121-5/+5
| | | | | | | | As per ### Qt6 comment. Also rename the LibraryLocation enum to LibraryPath. Change-Id: I556025a19c5bcdf2ff52598eaba32269522d4128 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove most compiler warnings about missing overridesLars Knoll2020-09-111-2/+2
| | | | | | | | | | | | 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>
* Deliver Quit event when calling QCoreApplication::quit()Tor Arne Vestbø2020-09-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of QCoreApplication::quit() directly calling exit(0), which would leave QGuiApplication and client code out of the loop, we now send the Quit event, and let it pass through event delivery, before finally ending up in QCoreApplication::event(), where we call exit(0). This has the advantage that QGuiApplication can ensure all windows are closed before quitting, and if any of those windows ignore the close event the quit will be aborted. This aligns the behavior of synthetic quits via QCoreApplication::quit() with spontaneous quits from the platform via QGuiApplicationPrivate::processApplicationTermination. Clients who wish to exit the application without any event delivery or potential user interaction can call the lower level exit() function directly. [ChangeLog][QtGui] Application termination via qApp->quit() will now deliver Quit events to the application, which in turn will result in application windows being closed as part of the application quit, with an option to cancel the application quit by ignoring the close event. Clients who explicitly want to exit the application without any user interaction should call QCoreApplication::exit() explicitly. Task-number: QTBUG-45262 Task-number: QTBUG-33235 Task-number: QTBUG-72013 Task-number: QTBUG-59782 Change-Id: Id4b3907e329b9ecfd936fe9a5f8a70cb66b76bb7 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Rename confusingly named QFont/QPalette::resolve overloadsVolker Hilsheimer2020-08-251-5/+5
| | | | | | | | | | | | | | | 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 <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Move QStringRef and remains to Qt5CompatKarsten Heimrich2020-08-201-1/+1
| | | | | | | | | Export some private functions from QUtf8 to resolve undefined symbols in Qt5Compat after moving QStringRef. Task-number: QTBUG-84437 Change-Id: I9046dcb14ed520d8868a511d79da6e721e26f72b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Ensure styles always get to polish the application paletteTor Arne Vestbø2020-07-211-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before 0a93db4d82c051164923a10e4382b12de9049b45 we would polish the application palette even when it was the default palette, as we always recreated the system palette each time a style was set. After the change we skipped polishing the palette unless it was set by the user, under the assumption that the style would set its own default palette if it wanted to override the system palette. This turned out to break the style's ability to slightly tweak the palette via polish (versus the more full on standardPalette approach). We now polish both the default palette and user palettes, and we do so as part of the normal palette update logic. This ensures that the style also gets a chance to polish the palette when the platform theme changes. The polish will not have an effect on the resolve mask of the palette, as the polish is conceptually the same as a base palette, and should not affect e.g. Qt::AA_SetPalette. Fixes: QTBUG-85469 Fixes: QTBUG-85188 Pick-to: 5.15 Change-Id: I869e9c442b177de4f1dc49eb75220709306f4d12 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Refactor pointer event hierarchyShawn Rutledge2020-07-101-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Introduce QInputDevice hierarchy; replace QTouchDeviceShawn Rutledge2020-06-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove winrtOliver Wolff2020-06-061-15/+0
| | | | | | | | | Macros and the await helper function from qfunctions_winrt(_p).h are needed in other Qt modules which use UWP APIs on desktop windows. Task-number: QTBUG-84434 Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QApplication: refactor delivery and propagation of wheel eventsVolker Hilsheimer2020-05-131-18/+55
| | | | | | | | | | | | | | | | | | | | | | | | Handle wheel grabbing via wheel_widget in a single place, and propagate events in the same way for all (spontaneous) events. Handle ScrollMomentum the same way as ScrollUpdate to allow partial sequences. Fix the incorrect ignoring of wheel events by default; like all other input events, they are now again accepted by default and ignored in the default event handler implementation of QWidget. This way, implementing the handle suffices to accept the event. Note that QWidget::wheelEvent doesn't need to be changed, as the event is ignored there today (an oversight of the change made in f253f4c3, perhaps). This also fixes changing of direction of a wheel event while the event sequence is grabbed by a widget. Change-Id: Ia0f03c14dede80322d690ca50d085898a0497dbe Fixes: QTBUG-67032 Task-number: QTBUG-79102 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QApplication: deliver all wheel events to widget that accepts the firstVolker Hilsheimer2020-04-251-0/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For kinetic wheel events, Qt tries to make sure that all events in the stream go to the widget that accepted the first wheel event. It did so by directing all events from the stream to the widget from which the spontaneous event was returned as accepted. However, that widget might have passed the event on to some other widgets; e.g QScrollArea forwards wheel events from the viewport to the relevant scroll bar. The event might then have come back accepted only because parent propagation kicked in (the scrollbar might not accept the event, so the parents get a chance, and some parent's scrollbar ultimately accepts the event). In this scenario, the wheel widget would be the viewport under the mouse, when it should have been the scrollbar of the parent. The next events from the stream were then delivered to a widget that didn't scroll; and parent propagation is not (and should not be) implemented for the case where Qt has a wheel widget. Instead, make the first widget that accepts any initial wheel event the wheel widget, even if the event was not spontaneous. With this change, all events from the stream are delivered to the widget that actually handled the event. That has the effect that ie. a viewport of a scroll area only gets the first event; all following events are delivered directly to the scrollbar. The test case added simulates the different scenarios - nesting of scroll areas, classic wheel events and a stream of kinetic wheel events. [ChangeLog][QtWidgets][QApplication] Wheel events from a device that creates an event stream are correctly delivered to the widget that accepts the first wheel event in the stream. Change-Id: I5ebfc7789b5c32ebc8d881686f450fa05ec92cfe Fixes: QTBUG-79102 Pick-to: 5.15 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove deprecated ApplicationAttribute enum valuesVolker Hilsheimer2020-04-241-12/+11
| | | | | | | | In the declaration, leave them in as comments so that the gaps in the numbering of the values doesn't create confusion. Change-Id: I92ff299416896c471e7c7d80b988cd4642b6b756 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QApplication: remove obsolete globalStrut functionalityVolker Hilsheimer2020-04-101-2/+0
| | | | | | Change-Id: If56873f86f5291264cac720f8db7dbd4db756f49 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-04-061-0/+7
|\ | | | | | | | | | | | | Conflicts: src/corelib/kernel/qeventdispatcher_win.cpp Change-Id: I32db3f755577aefc15f757041367d6144f5e5c66
| * Fix flakiness in tst_QApplication::testDeleteLaterAlex Trotsenko2020-04-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | DeleteLaterWidget is a main application window of the test. So, its show() function should be called explicitly before starting the main event loop. Otherwise, it remains hidden for the whole time, which causes an incorrect emission of QApplication::lastWindowClosed signal when a dialog window is closed in the middle of the test. Also, fix synchronization between deferred deletion and timer event. Change-Id: Id3ce5adbcd9e5e22508825c52025eeea70202354 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-04-031-69/+81
|\| | | | | | | | | | | | | Conflicts: tests/benchmarks/corelib/text/qstringlist/qstringlist.pro Change-Id: Ie9b97bd83c2df00fd9b556b5f09d405f71970169
| * Speed up tst_QApplication::testDeleteLaterProcessEvents2()Friedemann Kleint2020-03-311-1/+2
| | | | | | | | | | | | | | | | Quit the event loop once the object is destroyed. Change-Id: I6df1cfe867daacb6af56eb84646be91d98a2f545 Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 09:26:45 +0000