"libraryPaths" and "libraryPaths_qt_plugin_path" test functions fail on
VxWorks, due to missing path to "/usr/local/Qt-6.9.0/plugins" which test
expects.
The exact reason of this failure is to be found.
We need to run tests on COIN for VxWorks as significant, and this test
prevents it, to reduce growing number of regressions and allow
iterative introduction of VxWorks as a supported platform.
Add QEXPECT_FAIL in library-path-related test function of
tst_QApplication for VxWorks.
Task-number: QTBUG-115777
Task-number: QTBUG-130736
Change-Id: I08bb8b3f4a776303f61aebd931e5f3ddf3f1f39e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When adding blacklist for tst_QFont::familyNameWithCommaQuote I've made
a mistake and blacklisted wrong data tag: instead of "commaSeparated",
which is actually passing on VxWorks, it should be
"commaSeparatedWeird".
Fix this by providing valid data tag for
tst_QFont::familyNameWithCommaQuote test function.
Task-number: QTBUG-115777
Task-number: QTBUG-130738
Change-Id: Ided95e47283a7a7c455df4206860f35a3a9e9f6f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When creating blacklists for parametric tests, I've misunderstand the
role of comma in parametric tests descriptor in BLACKLIST, thinking that
this is a separator when in fact it was just a part of parameter name.
This leads to tests not being actually blacklisted for VxWorks.
Fix this by blacklisting each data tag for test function separately.
Task-number: QTBUG-115777
Task-number: QTBUG-130070
Change-Id: Id282c361d965e24341cd656aec6b1514e2c1f84f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
If building within yocto the header paths might contain the dash
character which was not captured from regexes.
Example:
./tmp/work/cortexa72-cortexa53-crypto-mx8-poky-linux/qtbase
Change-Id: I035b8e4520abacc915de48d1b090e35e69d54b1d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We need it to decide whether to generate write-back operations when
compiling method calls on QML value types to C++.
Task-number: QTBUG-127174
Change-Id: I63d3c2fbbbd463451cee57ddf33fa42d21335ac6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We use it from many places in Qt that may run before QCoreApplication
has been created (officially not supported but it happens) and after it
has been destroyed. In particular, we have code in QtDBus that runs in
another thread after QCoreApplication has been destroyed and uses the
event system.
This is not a complete change for Qt 7, it's just a reminder for work to
be completed then.
Change-Id: Ie3a0fc665babafd9888dfffd6c551e42f87a9dbd
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
We've just created the object (we're still inside the constructor). No
one can have connected to the signals yet.
Change-Id: I1f499b3fc6d2089665bdfffda709e1efaa2c4865
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
It was duplicated in all three files. The remaining code is very
similar, but I don't think we want to merge it any further. For one
thing, we must set the thread-local variable before QAdoptedThread calls
the QObject constructor.
Change-Id: Iac9f7f7528085a1137d7fffdecf080a2b6e1aefe
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's a duplicate of QThreadData::threadId, but in a different type
(DWORD vs Qt::HANDLE).
Change-Id: I99b48f9e53788550db88fffd1132f077f0a40fa7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The adopted thread watcher thread on Windows was a massive hack: because
Win32's Thread Local Storage support[1] did not support registering a
destructor for the data, we couldn't use the same trick we did on Unix
to run some code on the adopted thread when it was about to terminate.
So instead we launched another thread (which would also be adopted so we
had to protect against being watched) to watch the adopted threads and
post notifications. This consumed more resources and also emitted the
QThread::finished() signal from the watcher thread, not the adopted
one. Plus, this could cause crashes if QtCore was unloaded while the
watcher thread was running.
We can now depend on C++11 thread_locals on Windows, which therefore
allows us to run code shortly before the thread's exit. This commit
copies code from qthread_unix.cpp introduced in commit
4fabde349f16b59f37568da2a4c050c6dd53a34e, not including the two-phase
cleaning up.
This allows us to remove the QThreadData destruction code from
QCoreApplicationData.
[1] https://learn.microsoft.com/en-us/windows/win32/ProcThread/using-thread-local-storage
Change-Id: I09deebfec02a15082a68fffd7f650427eabdee54
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The jerk with QProgressBar occurs when setTextVisible(false) is used.
Condition exists to handle repaint when text visibility is true but not
handled when text visibility is false.
Usage of auto leads to type confusions.
Add the logic to repaint for every 1 pixel change in the value when
text visibility is false.
Avoid using auto when type is obvious.
Pick-to: 6.8
Fixes: QTBUG-45048
Change-Id: I0fdc62c7aabdaef52bc4bdc20e82141a4a7d29d5
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The code tells that it's deprecated in 6.2, while the docs were
mentioning 6.1. Update the docs to use the correct deprecation version.
Amends 1bf48c16b166c80d208f130fb4f8130f63ef741c.
Pick-to: 6.8 6.5 6.2
Change-Id: I4ec3b8e840ec5aa534ea1f2687a23584178bb4a6
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
We might want to raise the minimum CMake version for building or using
Qt, while keeping the minimum and maximum CMake policy NEW values
lower than the CMake min/max versions, because bumping the policy
values requires more testing.
Previously we always used the min cmake version as the lower range
for the policies.
Split QT_MIN_NEW_POLICY_CMAKE_VERSION and
QT_MAX_NEW_POLICY_CMAKE_VERSION
into per-type variables:
- QT_MIN_NEW_POLICY_CMAKE_VERSION_QT_SHARED
- QT_MIN_NEW_POLICY_CMAKE_VERSION_QT_STATIC
- QT_MIN_NEW_POLICY_CMAKE_VERSION_QT_APPLE
- QT_MAX_NEW_POLICY_CMAKE_VERSION_QT_SHARED
- QT_MAX_NEW_POLICY_CMAKE_VERSION_QT_STATIC
- QT_MAX_NEW_POLICY_CMAKE_VERSION_QT_APPLE
And change qt_internal_upgrade_cmake_policies to use the min new
policy as the lower range, instead of the min cmake version.
Pick-to: 6.8
Task-number: QTBUG-131169
Change-Id: Ib39a377edf20e497dc8f7d742b48d102a66c6a95
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously we used the TARGET_FILE genex as the destination where
to place the extracted dSYM bundle of an app in the build folder. For
Qt apps that have the MACOSX_BUNDLE property set, this is incorrect,
because it placed the dSYM bundle inside the app bundle.
We then manually install the dSYM bundle to the correct location.
Because the build folder app bundle still contains the dSYM
bundle, and CMake copies the entire app bundle dir when installing the
app, this resulted in installing the dSYM bundle twice.
Aside from waste of space, this is also against the Apple guidelines,
and leads to certain issues with code-signing.
Check the MACOSX_BUNDLE property to determine if the executable is a
bundle, in which case treat it the same way we treat framework
bundles, by placing the dSYM bundle next to the app bundle.
Pick-to: 6.8
Change-Id: I7fb8fe49e0b26d0df8a32fc82530bbee32b51382
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Currently the separate debug info handling is done inside the call of
qt_internal_add_executable. But there might be extra properties set
after the executable is created, which we might want to consider when
handling the separate debug info, like whether the executable is a
macOS bundle.
Introduce a new qt_internal_finalize_executable finalizer. Move the
separate debug info handler to be called in this finalizer.
To be consistent run the separate debug info handler in a finalizer
for qt tools as well.
Pick-to: 6.8
Change-Id: I46412249aaab099628a50b11efff541f5719aff5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In this configuration there is one thread (as far as Qt is
concerned), and that is the main thread.
Change-Id: I6817961a0f95f2e8b1bb3ea120154d954f1eaf0f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Even Oscar Andersen <even.oscar.andersen@qt.io>
If the QT_BUILD_ENVIRONMENT is set to ci, add --verbose
by default.
Pick-to: 6.8
Change-Id: Ia9f2ba4c0191649d43a17bd76f61ca46180345d7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
X11 spawns painting threads and sends an expose event at the same time.
While the worker is still paining, QXcbScreen::topLevelAt() may not
find the window, even if it reports being exposed.
Wait until windows are exposed and painted.
Remove workaround to intercept warnings about undeliverable gestures.
Remove qWait() antipattern.
Fixes: QTBUG-130811
Fixes: QTBUG-84258
Fixes: QTBUG-69648
Fixes: QTBUG-67393
Fixes: QTBUG-67392
Fixes: QTBUG-67389
Fixes: QTBUG-68861
Fixes: QTBUG-70224
Fixes: QTBUG-70223
Fixes: QTBUG-67395
Fixes: QTBUG-70227
Fixes: QTBUG-70226
Fixes: QTBUG-70209
Fixes: QTBUG-70153
Pick-to: 6.8 6.5
Change-Id: Id126fe884ba360551425f3e2b29674f5b9419fff
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The list of available QPA platforms and the default QPA platform is now
available in modules/Gui.json.
Change-Id: I059286d80c8507080d5ec3d790cf8ea22c5daddd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The linked issue reports a lack of information about multi-arch builds
of Qt on Apple platforms. In order to add the information we take the
chance to rework the structure of the module JSON files and make the
format future-proof for when we'll create multi-platform
bundles (xcframeworks).
The new module JSON files differ from the old ones in the following
points:
- The 'schema_version' key denotes the version of the module JSON file
schema. It's set to 2.
- The 'built_with' key was removed. The relevant information was moved
to 'platforms' entries.
- The 'cross_compiled' key was removed. It was only used to determine
whether a Qt build contained host tools. Since one needs the actual path
to host tools anyway, it's more useful to query qtpaths for that
information.
- A 'platforms' key was added that holds a list of target platforms.
Currently, only an iOS simulator-and-device build has more than one
platform:
"name": "iOS",
"variant": "iphoneos",
and
"name": "iOS",
"variant": "iphonesimulator",
- A 'targets' key was added under each 'platforms' entry. This contains
information about the target architecture(s) and other relevant
properties.
- The 'android' key was flattened and moved to the 'targets' entries.
[ChangeLog][CMake] The structure of the module JSON files, e.g.
modules/Core.json has been reworked. Consumers of these files need to be
updated. A 'schema_version' key was added and set to 2 to ease reading
different versions of these files.
Fixes: QTBUG-129996
Change-Id: I5a6ac9746aa19ad0ee9f2d020bf7486bdac28226
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...in a multi-architecture build on macOS.
Our "architecture" configure test only retrieved and stored information
about the first architecture, even if CMAKE_OSX_ARCHITECTURES contained
multiple values.
Now, we run that configure test once for every entry in
CMAKE_OSX_ARCHITECTURES, extract the information from the test binary,
and store
- a list of architectures,
- a list of subarchitectures per architecture,
- the build ABI per architecture.
For example, for a build of Qt with CMAKE_OSX_ARCHITECTURES=x86_64;arm64
we now set the following cache variables.
For the first architecture:
TEST_architecture_arch=x86_64
TEST_subarch_result=cx16;sse3;ssse3;sse4.1
The list of architectures:
TEST_architecture_architectures=x86_64;arm64
Sub-architectures and ABI per architecture:
TEST_arch_arm64_abi=arm64-little_endian-lp64
TEST_arch_arm64_subarch_crc32=1
TEST_arch_arm64_subarch_crypto=1
TEST_arch_arm64_subarch_neon=1
TEST_arch_x86_64_abi=x86_64-little_endian-lp64
TEST_arch_x86_64_subarch_cx16=1
TEST_arch_x86_64_subarch_sse3=1
TEST_arch_x86_64_subarch_sse4.1=1
TEST_arch_x86_64_subarch_ssse3=1
This is mainly done to provide all ABIs in our module JSON files but
hopefully comes in handy in other situations as well.
Change-Id: Idacd82fc87523657b8bb6ec0c0424f2361572dce
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's already automatically added as part of the license iteration code
in _qt_internal_sbom_begin_project which globs
${PROJECT_SOURCE_DIR}/LICENSES/LicenseRef-*.txt and adds those.
Adding it a second time manually is unnecessary, and breaks conversion
to SPDX 3.0 with the spdx java preliminary tool.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: Id42a02c6f2e536880b37a0ed773cf62426b46b97
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If an entry in the list from the system query exercises a legacy tag,
the QLocaleId it gets converted to has a name() that's different from
it. The check that this name matches the list item that it's derived
from was consequently failing. Have that check fall back to actually
doing the round-trip via parsing to compare the name, if the (still
cheaper, so retained) naive check fails.
Fixes: QTBUG-131127
Change-Id: Ifa004deff880109031ff56be00bebff6f5106e62
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since the C++20 spaceship operator <=> appeared in the standard,
qtest framework starts using it for tests. To make the way of
usage the spaceship operator convenient and informative,
the QCOMPARE_3WAY macro is added.
- Add QCOMPARE_3WAY macro usage testcases.
- Add threewaycompare test to setftests.
[ChangeLog][QtTest] Added the QCOMPARE_3WAY macro. The macro
tests the C++20 spaceship operator <=>
Fixes: QTBUG-104108
Change-Id: Ia14b26c1d70625ac8c6cf2278d597b2a8cbe31d0
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The Java callback function onDataChanged() gets called
from Android UI thread. QTRY_COMPARE on the result of
a JNI call does not make sense because it actually does
not retry to reinvoke the JNI call to read the related
counter.
This change puts the JNI call to QTRY_COMPARE to make sure
the Android thread have to to process the Runnable.
Fixes: QTBUG-131253
Change-Id: Icdff8f8f37b33968f5a3f6e545ce753907305e74
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Never set the VK_IMAGE_ASPECT_STENCIL_BIT aspect mask when creating
texture ImageViews.
If both the depth and stencil aspects are needed in the descriptor set,
we would probably need to create two separate image views, e.g.:
// Depth
vkCreateImageView(rhiD->dev, &depthViewInfo, nullptr, &dv);
views.append(dv);
// Stencil
VkImageViewCreateInfo stencilViewInfo = depthViewInfo;
stencilViewInfo.subresourceRange.aspectMask =
VK_IMAGE_ASPECT_STENCIL_BIT;
vkCreateImageView(rhiD->dev, &stencilViewInfo, nullptr, &sv);
views.append(sv);
These are the two errors faced with a D32 and D24S8 texture:
vkCreateImageView(): Using format (VK_FORMAT_D32_SFLOAT) with aspect
flags (VK_IMAGE_ASPECT_DEPTH_BIT|VK_IMAGE_ASPECT_STENCIL_BIT) but depth-
only image formats can have only the VK_IMAGE_ASPECT_DEPTH_BIT set. The
Vulkan spec states: subresourceRange.aspectMask must be valid for the
format the image was created with (https://www.khronos.org/registry/
vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkImageViewCreateInfo-
subresourceRange-09594)
vkUpdateDescriptorSets(): pDescriptorWrites[2].pImageInfo[0].imageView
use layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL and the image format
(VK_FORMAT_D24_UNORM_S8_UINT), but it has both STENCIL and DEPTH aspects
set. The Vulkan spec states: If imageView is created from a depth/
stencil image, the aspectMask used to create the imageView must include
either VK_IMAGE_ASPECT_DEPTH_BIT or VK_IMAGE_ASPECT_STENCIL_BIT but not
both (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/
vkspec.html#VUID-VkDescriptorImageInfo-imageView-01976) The doc indeed
states that: When using an image view of a depth/stencil image to
populate a descriptor set (e.g. for sampling in the shader, or for use
as an input attachment), the aspectMask must only include one bit, which
selects whether the image view is used for depth reads (i.e. using a
floating-point sampler or input attachment in the shader) or stencil
reads (i.e. using an unsigned integer sampler or input attachment in the
shader).
Pick-to: 6.7 6.8
Change-Id: Ic35ead318fb1130eaa8f9ff3585da38e32566b95
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
A recent update [0] to the IANA timezone database has improved the
historical accuracy of transitions in Mexico. It turns out that the
transition at the start of 1970 was not a real event. The only actual
change then was that Mazatlan has followed the main Mexico zone rules
since then, having ignored some transitions of the main zone in
earlier decades.
[0] 812aff32b3
Pick-to: 6.8 6.8.1 6.5
Fixes: QTQAINFRA-6757
Change-Id: I65d8ea1dfa76ce635bf11ffcc1ded8c9ceaf9fec
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Avoid lint exception for dependency updates in
the developer build so we do not miss updates.
Pick-to: 6.8
Change-Id: I7856a2773e49258c6497ae5d4978a4ea519e9a04
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This would make paths in warning/error messages absolute
also, being more clear which module it is from and another
benefit is it being clickable from various IDEs in case the
qt5 repo is opened as a project and not only single modules.
Change-Id: Ic95cea0005f0675186ad700e197e217dad016876
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a note on how timestamps are handled for the different database
drivers.
Pick-to: 6.8
Task-number: QTBUG-130118
Change-Id: I1bad480fa18b5b719870635db1444c8db8c7d966
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Use the propagated interface property to collect the plugins for the
android deployment. This method allows collecting plugins from the Qt
libraries without using walk-libs approach with all its disadvantages.
The only limitation is the CMake version, since custom transitive
properties support was added in the CMake version 3.30.
For now it's only uses in Android deployment, will be spread wider
in followup commits.
Fixes: QTBUG-129302
Change-Id: I8d5ae7342d57d215021ad02c51dda44f88c9a920
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use the freshly introduced TRANSITIVE_COMPILE_PROPERTIES functionality
to handle plugin targets across Qt modules. This will allow accessing
all Qt plugins that are required for targets at once, without the need
of iterating over the Qt targets at configure time.
This mechanism duplicates the already existing plugin collecting
routines, since we still need to support the older CMake version.
This commit only introduces the helper functions and plugins collecting,
but doesn't use the QT_PLUGIN_TARGETS anywhere.
We don't use the direct export of properties by CMake but still rely on
plugin collecting mechanism we use before to cover the situation when
Qt is built using CMake versions < 3.30 and then is used to build user
applications with CMake versions >= 3.30.
Task-number: QTBUG-129302
Change-Id: Id3b516b92e8e16552d46b2c702b76c571366f2b5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Commit 1ed0dd88a32cd2c5ae100b48e14ff55bcbb652e6 ("QThread/Unix: make
QThreadPrivate::finish() be called much later") introduced this problem.
Commit 4fabde349f16b59f37568da2a4c050c6dd53a34e split the thread
termination in two phases, but did not fix this.
This re-applies commit 950b35cf97ad398f97883efd2a18ee97994a8a9c ("Clear
the current thread data for the main thread"), which was reverted in
commit 7dc622290bb8e81af634034f443e25be0d6d48a3 ("Make sure QThreadData
and QAdoptedThread object is destroyed at app exit"), both from Qt 5.1.
Between Qt 5.1 and 6.7, the responsibility of clearing the
QAdoptedThread for the main thread was split: it could occur either in
~QCoreApplicationData if exit() was called in that thread or in
~QThreadData() if it wasn't (e.g., when the Qt "main thread" is not
main()'s thread):
* frame #0: 0x0000000101db8a28 QtCore`QAdoptedThread::~QAdoptedThread(this=0x000060000176c070) at qthread.cpp:139:1
frame #1: 0x0000000101db81eb QtCore`QThreadData::~QThreadData(this=0x0000600002468000) at qthread.cpp:82:5
frame #2: 0x0000000101db8379 QtCore`QThreadData::~QThreadData(this=0x0000600002468000) at qthread.cpp:57:1
frame #3: 0x0000000101db841c QtCore`QThreadData::deref(this=0x0000600002468000) at qthread.cpp:108:9
frame #4: 0x0000000101f4ec79 QtCore`destroy_current_thread_data(p=0x0000600002468000) at qthread_unix.cpp:104:11
This commit centralizes and gives ~QThreadData() the exclusive
responsibility. That requires not resetting QThreadData::threadId so
~QThreadData can know it is theMainThread.
Fixes: QTBUG-130895
Task-number: QTBUG-129927
Task-number: QTBUG-129846
Task-number: QTBUG-130341
Task-number: QTBUG-117996
Pick-to: 6.8
Change-Id: Ie3f3cbdc5523837b505cfffd95fba5e6498b5069
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QCoreApplicationPrivate::mainThread() asserts that there is a main
thread, which means we can't use it to detect after the main thread has
been unset (late destructor-on-exit).
Pick-to: 6.8
Change-Id: Iedcd0827d1e659f3de35fffd60cac0b47cc496bb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Partially reverts commit 65953e05d3d9aefd158d4073820083155aaae5e4 (the
rest will be addressed in the next commit) now that we have an atomic
access to the QCoreApplication instance.
This thread-affinity check code was there because the code had a data
race in accessing QCoreApplication::self. It ensured that we only read
that variable if the receiver was in the main thread, because if a
receiver is not in the main thread, then it can't be QCoreApplication.
Pick-to: 6.8
Change-Id: I09618961cca80fef2dc1fffdab65316164023207
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
We use it from many places in Qt that may run before QCoreApplication
has been created (officially not supported but it happens) and after it
has been destroyed. In particular, we have code in QtDBus that runs in
another thread after QCoreApplication has been destroyed and uses the
event system. Accessing QCoreApplication::self anywhere but the main
thread was a race condition in those conditions.
Pick-to: 6.8
Change-Id: If4ad1af9301dca98ba69fffdf88c63b220db53ac
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Otherwise the download fails. We need to provide both the encoded path,
and the name for the local file, as cmake doesn't provide an encoding
helper.
Pick-to: 6.8
Change-Id: Id2d1c197f9ee1326ee229ebd32e5af156c970aed
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The test case was missing the identifier before two of the animations.
Although it did not affect the result of the test, it was using an
incorrect CSS syntax to define the animations.
Change-Id: I1d7930aa99b95733e0afb0a033eea219038baf99
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Avoid casting an event to a type it does not have. Instead use a static accessor class.
Pick-to: 6.8
Task-number: QTBUG-99563
Change-Id: Ideb11779b1510cd10a27fb8bc40bcc8e4849bf15
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Qt used to accept a canvas created by user code. This
is no longer supported and user code should provide a
div container element instead.
Make this an error case with a qFatal()
Change-Id: I5c5ceef85916632bd95347546a8098b9a650afa6
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The CMake copy_if_different command, which copies the android target
library to a libs/<arch> directory could be executed in different code
paths which caused a multiple access to a same file in a filesystem.
Avoid doing this and depend on <target>_prepare_apk_dir target for the
depfile code path too.
Pick-to: 6.5 6.8
Change-Id: Ib62cf24ecc69a17ce1b52cd1f001aeff866051cd
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
