This commit adds one unusual creation and three more unusual exits:
* creation of the Q*Application in a thread (QTBUG-130895)
* exits using ::exit() instead of returning from main():
* from the main thread's event loop
* from an auxiliary thread
* from inside an auxiliary thread's event loop
All of these exercise the moment the QAdoptedThread & QThreadData for
the main thread is destroyed, which are, respectively:
* thread exit time, running thread-specific destructors
* inside exit(), running atexit()-like callbacks (qthread_*.cpp)
* [tst_static_q*application] inside exit(), running static destructors
(added in commit 1da7558bfd7626bcc40a214a90ae5027f32f6c7f)
Unlike the tst_static_q*application tests, the calls to ::exit() cannot
be a regular QtTest because that would cause the log output to be
incomplete. The threaded Q*Application could be a test of its own, but
since I needed to add the helper anyway, I chose to add the test there.
For the majority of the tests, the failure mode is going to be a crash
on exit.
Task-number: QTBUG-12673
Task-number: QTBUG-132429
Change-Id: I1062ef500356bd97dd0cfffda4aeeda9afa138e8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit bfbd1a281dd00c47df315c06e895bf5d53cd8764)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit ea6d467c050c9e4ab58f970f6720b428ec43c8e2)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Amends 65093a84c2b94b1543fd4593bc45d491951d28d4, which changed how we
destroyed the main thread's QThreadData. This merges the call to
destroy_current_thread_data() for both types of Unix systems: those with
broken thread_local destructors and those with working ones. It turns
out that the function got called too early for us in those working
systems (see updated comment).
The clean up of the QThreadData is split into two different mechanisms:
* for any auxiliary thread, when it exits, PThread will call back to
destroy_current_thread_data()
* for the thread that called ::exit(), PThread won't, but ::exit() will
invoke set_thread_data()::TlsKey's destructor
This is different from the situation that existed prior to commit
65093a84c2b94b1543fd4593bc45d491951d28d4: first, there's no code in
qcoreapplication.cpp for this (all in qthread_unix.cpp). Second one may
call ::exit() from any thread, whether that is the thread that called
main(), the thread Qt thinks is theMainThread, or any other.
This commit moves the tst_QCoreApplication check for no extant objects
to a new test. I've chosen to add a new test instead of running a helper
binary via QProcess because we do have a couple of !QT_CONFIG(process)
platforms in the CI, and this is too important.
Credit to OSS-Fuzz for finding this, though it is not itself a fuzzying
problem (all tests of a given structure were crashing on exit).
Fixes: QTBUG-132381
Task-number: QTBUG-130895
Task-number: QTBUG-129927
Task-number: QTBUG-129846
Task-number: QTBUG-130341
Task-number: QTBUG-117996
Change-Id: Ie294dce7263b4189f89ffffd9155ec71d31b89d9
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 1da7558bfd7626bcc40a214a90ae5027f32f6c7f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 6dc19b55fc6d6dd3198b744f713101cf3b77c0c8)
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
As part of df359bcb70 the semantics and
interaction between QEventLoopLocker and QGuiApplication was changed,
based on the assumption that these two mechanisms were independent
and should not affect each other.
This had a surprising regression where the use of QEventLoopLocker in
combination with the QCoreApplication::isQuitLockEnabled() automatic
quit would end up quitting the app, even if it had open windows, for
example when the last job of some internal job queue finished.
It could be argued that if the app has open windows that should not
be closed, they should ignore the Close event, and that an application
with running QEventLoopLocker jobs should maintain an active window
showing the progress of those jobs, but still, this is regression
that we want to fix.
We now bail out if !lastWindowClosed() in QGuiApplication's
canQuitAutomatically, which is triggered from QEventLoopLocker's
isQuitLockEnabled() behavior. And we do so regardless of whether
quitOnLastWindowClosed is set or not, as the latter property
determines the behavior when closing a window, not the behavior
when a QEventLoopLocker goes out of scope.
Similarly, we now block quitting of the application when triggered
by quitOnLastWindowClosed() if a QEventLoop is active, regardless of
the isQuitLockEnabled(), as the latter property is determining
whether we should trigger a quit, not whether we should block them.
[ChangeLog][Important behavior changes] Fixed a regression where
the last QEventLoopLocker going out of scope would quit the app,
even if there were open windows, if quitOnLastWindowClosed was
false.
[ChangeLog][Important behavior changes] Fixed a regression where
closing the last window would quit the app, even if there were
active QEventLoopLockers, if isQuitLockEnabled was false.
Fixes: QTBUG-124386
Pick-to: 6.7 6.5
Change-Id: I84fd0ddea78a2f417f3a17b326113c880079cf85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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>
Although not explicitly documented, this is the behavior in practice
on XCB and Windows, and we rely on this behavior in our implementation
of QApplication::widgetAt(), where we punch a temporary hole in the
widget using a mask if it has Qt::WA_TransparentForMouseEvents set.
Pick-to: 6.5 6.6
Fixes: QTBUG-41696
Task-number: QTBUG-119092
Change-Id: Ie7abc31b6930ee6b56fcdf391befc625c1ddf502
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Under some circumstances (e.g. setDesktopSettingsAware(false) on
windows) it may happen that the call to platformTheme::palette() returns
a nullptr which is not checked before dereferencing the pointer.
Therefore add a check for this to avoid a crash.
Fixes: QTBUG-111527
Change-Id: I6443d5d1a9b813f499d8f65b4fee55b0b8299b16
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Add the boilerplate standalone test prelude to each test, so that they
can be opened with an IDE without the qt-cmake-standalone-test script,
but directly with qt-cmake or cmake.
Boilerplate was added using the following scripts:
https://git.qt.io/alcroito/cmake_refactor
Manual adjustments were made where the code was inserted in the wrong
location.
Task-number: QTBUG-93020
Change-Id: I2ef59684cf297a0222a136ce7b5630037294d000
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The desktop file name should not contain ".desktop" suffix, but some
applications still specify it anyway because of the ambiguity in the
documentation that was fixed in
0c5135a9df.
This change makes setDesktopFileName remove ".desktop" suffix so
desktopFileName always returns a desktop file name with correct format
and its users don't need to chop ".desktop".
Pick-to: 6.5
Change-Id: If5abccaf3bf976449cada8891fff887870e45b5f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
The paletteChanged() and fontChanged() signals were deprecated
in Qt 6.0, but the test was still using them unconditionally.
This patch guards the usage of the deprecated signals with
the usual QT_DEPRECATED_SINCE(6, 0) check, so that the test
can be built and run with QT_DISABLE_DEPRECATED_UP_TO >= 0x060000
This commit amends 68ea9c0227
Task-number: QTBUG-104858
Change-Id: Idb2da6d91afcdb664f325f23ec625947c9a7fac0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The new name describes the behavior in a better way.
[ChangeLog][Build System] The QT_DISABLE_DEPRECATED_BEFORE macro is
renamed to QT_DISABLE_DEPRECATED_UP_TO. The old name is deprecated, but
is still recognized if it is defined during configuration and the new
name is not defined.
Task-number: QTBUG-104944
Change-Id: Ifc34323e0bbd9e3dc2f86c3e80d4d0940ebccbb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
+ I could not reproduce the flakiness on OpenSUSE Tumbleweed.
+ No significant flakiness can be seen for this test in our testresults
statistics.
+ Ubuntu-16.04 is no longer part of our CI
Change-Id: I7a18fc3fe2e58af8533171ebae0457b08424e810
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
... 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>
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>
The stored layout direction used to get changed during initialization
to what was auto-detected based on the translation. Changing the
translation then overwrote that stored value, even if an explicit call
to setLayoutDirection was made by the application.
Calling QGuiApplication::setLayoutDirection(Auto) has so far been a
no-op.
Change this logic so that the stored layout direction continues to be
LayoutDirectionAuto also if it's set based on auto-detection, and only
overwrite it when explicitly called with a non-Auto value. This way,
applications can set a layout direction that stays unchanged even when
translators are installed.
Add test coverage that uses a QTranslator.
In practice, this is not a change of behavior, unless applications called
setLayoutDirection(Auto) (which is no longer a no-op), or called
setLayoutDirection() and then installed a translator and expected the
translator's layout direction to come into effect in spite of the explicit
setting.
[ChangeLog][Gui][QGuiApplication] Calling setLayoutDirection with a non-
auto value now disables the auto-detection based on installed
translators. Applications that explicitly set a layout direction and also
want translators installed afterwards to take effect should reset the
layout direction to Auto, which is now no longer a no-op.
Fixes: QTBUG-100632
Pick-to: 6.3
Change-Id: I1fdcebd43a9b1b468ff95bf15f53f441bb214e08
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
In tst_qguiapplication and tst_qcoreapplication,
the application version should be set. On Android, this
is done using QT_ANDROID_VERSION_CODE.
Pick-to: 6.2 6.3
Change-Id: I6b473ad25092fb24df9400e0ab8fbb8ea4edbb6a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
on Wayland
Task-number: QTBUG-100891
Pick-to: 6.3 6.2
Change-Id: Iadf12364ded4549988ad75a9487c7e96e963a956
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
tst_qcoreapplication.cpp is used both in tst_qcoreapplication and
tst_qguiapplication. To distinguish these two compilations,
the define QT_GUI_LIB was used. This led to an error on Android,
where Qt::Gui is always linked, because the Qt Android Platform
Plugin needs it.
This patch introduces the preprocessor define QT_QGUIAPPLICATIONTEST
which is to be used only in the compilation of tst_qguiapplication.
This is then used instead of QT_GUI_LIB.
Change-Id: Ifa5bfacb197d68365288c1da85573106515fc6c2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Multiple tests use qt_internal_add_resource that copies the
functionality that is already implemented inside the
qt_internal_add_test function. Simplify these test by replacing
the qt_internal_add_resource call with the new BUILTIN_TESTDATA
option.
Change-Id: I18475b817d6f87264f0de53817d6c26c5ccab4e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a512e210ac5b032c5fc2edf1ddf72e5a414485fda512e21 quitOnLastWindowClosed
was changed to be implemented in terms of quitLockEnabled, but without
any documentation to that end.
Although the two features are similar (automatic quit under certain
conditions), and interact, it doesn't make sense to overlap them until
we actually expose them as a single property (automaticQuit e.g.)
The logic for determining whether we can can quit automatically has
been refactored to take both properties into account, on both a Core
and Gui level. The call sites still need to check the individual
properties to determine whether to activate automatic quit for
that particular code path.
Change-Id: I38c3e8cb30db373ea73dd45f150e5048c0db2f4d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
They return a pointer to the actual header, skipping the magic string.
This is done in preparation for the header located in an ELF note, which
won't have the magic.
Change-Id: I3eb1bd30e0124f89a052fffd16a8229bec2ad588
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
After the recent refactoring in 28b14b966f
this test should run stable on all platforms. However, the way the test
was written made it quite flaky. Simplify it to verify that closing one
window doesn't prevent a second timer to fire (which it would if closing
the first window already quit the application).
Change-Id: I0306792cd7573ebd3418d1aabffe2b78700ec2d9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Verifies that we get the messages we want, and makes it easier to see
relevant debug output.
Pick-to: 6.2
Change-Id: Ide92959b120f325badbf200236cdc85f72226e1e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Those serve no purpose anymore, now that the .pro files are gone.
Task-number: QTBUG-88742
Change-Id: I39943327b8c9871785b58e9973e4e7602371793e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
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>
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>
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>
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>
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>
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>
mkspecs/features/qt.prf adds a dependency on the system threading
library if the Qt Core thread feature is enabled. Because qt.prf is
loaded by any public or internal Qt project, it's essentially a public
dependency for any Qt consumer.
To mimic that in CMake, we check if the thread feature is enabled, and
and set the Threads::Threads library as a dependency of Qt6::Platform,
which is a public target used by all Qt modules and plugins and Qt
consumers.
We also need to create a Qt6Dependencies.cmake file so we
find_package(Threads) every time find_package(Qt6) is called.
For the .prl files to be usable, we have to filter out some
CMake implementation specific directory separator tokens
'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call
target_link_libraries() with a target created in a different scope
(I think).
As a result of this change, we shouldn't have to hardcode
Threads::Threads in other projects, because it's now a global public
dependency.
Task-number: QTBUG-85801
Task-number: QTBUG-85877
Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Use pro2cmake with '--api-version 2' to force regenerate
projects to use the new prefixed qt_foo APIs.
Change-Id: I055c4837860319e93aaa6b09d646dda4fc2a4069
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
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>
It simplifies the API and reduces surprise to have rotation working by default.
On Android, the manifest specifies which orientations the application has
been designed to support; on iOS, it is controlled via the
UISupportedInterfaceOrientations property list key.
In addition, QWindow::contentOrientation() is another way to give
a hint to the window manager, or on iOS to directly control whether
the window's rotation is locked or not.
Task-number: QTBUG-35427
Task-number: QTBUG-38576
Task-number: QTBUG-44569
Task-number: QTBUG-51012
Task-number: QTBUG-83055
Change-Id: Ieed818497f686399db23813269af322bfdd237af
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Test was failing due to missing windows resource files which contain the
version information for the executable.
Change-Id: I19b0c747c6b833bac64f3667e9286350e7842b7c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change-Id: I55cb9a6b3aebac68fb1b20127ba7aa501b4a3f2b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The logic is now mostly handled in QGuiApplication, with QApplication
only dealing with the widget-specific palettes and interaction between
the style and the palette.
The application now picks up changes to the platform theme and will
re-resolve the current application palette appropriately. This also
works even if an explicit application palette has been set, in which
case any missing roles are filled in by the theme.
The palette can now also be reset back to the default application
palette that's fully based on the theme, by passing in the default
constructed palette (or any palette that doesn't have any roles set).
This is also correctly reflected in the Qt::AA_SetPalette attribute.
Conceptually this means QGuiApplication and QApplication follow the
same behavior as QWidget, where the palette falls back to a base or
inherited palette for roles that are not set, in this case the theme.
Behavior-wise this means that the default application palette of the
application does not have any roles set, but clients should not have
relied on this, nor does QWidget rely on that internally.
It also means that setting a palette on the application and then
getting it back again will not produce the same palette as set,
since the palette was resolved against the theme in the meantime.
This is the same behavior as for QWidget, and although it's a
behavior change it's one towards a more sane behavior, so we
accept it.
[ChangeLog] Application palettes are now resolved against the platform's
theme palette, the same way widget palettes are resolved against their
parents, and the application palette. This means the application palette
reflected through QGuiApplication::palette() may not be exactly the same
palette as set via QGuiApplication::setPalette().
Change-Id: I76b99fcd27285e564899548349aa2a5713e5965d
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Thiago Macieira
Tor Arne Vestbø
Lucie Gérard
Liang Qi
Doris Verria
Christian Ehrlicher
Alexandru Croitor
Vlad Zahorodnii
Friedemann Kleint
Marc Mutz
Ivan Solovev
Dimitrios Apostolou
Volker Hilsheimer
Andreas Buhr
Alexey Edelev
Joerg Bornemann
Allan Sandfeld Jensen
David Skoland
Lars Knoll
Shawn Rutledge
Oliver Wolff
Leander Beernaert