Previously if a target depended on CorePrivate, we would write a
_qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a
FooDependencies.cmake file.
That find_qt_deps call would remove the 'Private' suffix and would run
find_dependency with NAMES set to both the altered and non-altered
names.
This would find the relevant package but it would set the wrong
_FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead
of Qt6Core_FOUND.
This in turn could cause multiple lookups of the Qt6Core package
during dependency handling because the correct _FOUND var would not be
set.
Instead of always looking for the Qt6CorePrivate package, make sure
we look for an appropriately named package for all Privates modules,
because we have the necessary info to determine the correct name.
Note that INTERNAL modules will still be looked up via a Private
suffixed package name because that's how the package name is chosen
for them.
Remove the code that accounted for Private modules in
qt_internal_remove_qt_dependency_duplicates because it's not needed
anymore.
Warn when a package name can't be queried from a target's property
because the target might not exist yet.
Add a TODO comment for the code that searches with two NAMES.
We can't remove it right now, because it might break user projects
that use stale Dependencies.cmake files.
The dbus subdirectory is added before the tools subdirectory
to ensure that the new package name extraction does not error out, due
to trying to access a target that does not yet exist.
Amends 425ff34aa1
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The ZLIB and the PCRE2 should be created before Core, because
src/corelib does qt_find_package to find the bundled / built
libraries.
The libpng, libjpeg, and the rest of the 3rd party libraries should be
created after the Core target is created, because they reference
Core conditionally in qt_internal_extend_target.
Targets should ideally be referenced only after they are created, when
creating linking relationships, but if code needs to extract
properties from those targets, then the targets must exist.
This will be the case in a future change which will extract the
package name from a target's property via qt_internal_extend_target ->
qt_register_target_dependencies chain.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I732827e5bb4c88532c1e5261ef753d73bda6e638
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
None of them have Qt sources that need moc-ing.
It's also needed to circumvent an AUTOMOC + PCH issue when AUTOMOC is
enabled for a target that does not have any C++ sources, but the
target links to another target that does have C++ sources.
Pick-to: 6.4
Change-Id: Ib1b2aa766089f093117c1ba34e156dfe8b0957e6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously we did not create Qt6:: namespaced aliases.
This is needed as a workaround preparation for getting the package name
of a module target from one of it's properties.
Before it would fail in qtinterfaceframework because
ifvehiclefunctions-simulation-server uses PUBLIC_LIBRARIES
in its qt_internal_add_app call, and because _add_app does not handle
such an option, some weirdness in qtbase's _add_app -> _add_executable
-> _extend_executable -> _register_target_dependencies ended up trying
to register PlatformAppInternal as package dependency.
That issue will be handled in separate changes.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ifd03528c95b08cb6837a6aaa26cbf97c0cbabbb4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When loading Qt packages, don't look for the Qt6 dependency if it was
already found in the given subdirectory scope.
This reduces the amount of find_dependency(Qt6) calls.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I737c4433daf30eed51a058b45cd539dff7657ca4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of trying to compute and validate the QT_HOST_PATH and
QT_HOST_PATH_CMAKE_DIR variables in the generated toolchain file,
do it in the Qt6 package.
This provides better error messages when a project is configured
without using the Qt generated toolchain file.
Because it's not done in the toolchain anymore, remove the various
host variables from __qt_toolchain_used_variables.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I1ca239ff83b8f783897e171fee352fc43e8ad7a8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of checking if QT_HOST_PATH is set during user project
configuration to find out if Qt6HostInfo should be looked up,
record if QT_HOST_PATH was provided during Qt configuration
into Qt6Dependencies.cmake and look up the package in a user
project based on that information.
This improves handling of the case where cmake is directly used
to configure a Qt project (instead of qt-cmake), which means no
QT_HOST_PATH might be set by the user, and then cmake would error out
saying that e.g. Qt6CoreTools is not found, instead of saying that
Qt6HostInfo is not found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Also replace the duplicate call in QtSetup using the
new function.
To do that, we have to actually the call it in QtBuild
after QtPublicDependencyHelpers.cmake is available.
That call is needed so that Qt6_HOST_INFO_foo variables
are available in qt_generate_qmake_and_qtpaths_wrapper_for_target.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ic5776c214bee6bedcea714b213b0e5a42c1bae06
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The definitions of the deprecated methods were not guarded by the
QT_DEPRECATED_SINCE() check, which causes compilation errors when trying
to get rid of the deprecated APIs using QT_DISABLE_DEPRECATED_BEFORE.
Task-number: QTBUG-105126
Pick-to: 6.4
Change-Id: Iff7a5bbde743b4351b98c58090da44fe05c4654a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
When an argument to one macro appears as a single argument to another
macro, the usual "put it in parentheses" rule doesn't apply since it's
necessarily something the right shape to be a macro parameter. In some
cases, furthermore, the added parentheses could show up in the output
produced by a test when reporting an expression that was compared or
verified. Also removed the parentheses around one comparison.
Pick-to: 6.4
Change-Id: I226f4356fb057351187dac2134cc12c06026c40c
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The macros' expansions end with an if-block and a for-block,
respectively, so the following semicolon is superfluous. Since we
control these macros' use (they're internals), just skip the
semicolons, rather than wrapping their bodies in do-while(0).
Pick-to: 6.4
Change-Id: I53f7786a66a0dc7709ac9f96d49985edafceec39
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
These checks should not be included in the #expr reported when the
test fails. They're an internal implementation detail of the loop.
Split a long line while I was about it.
Pick-to: 6.4
Change-Id: Iaea0478967d01cd72ef5a5e9a6501d4be2324b18
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The skipcleanup and failcleanup tests were actually testing skip and
fail in cleanupTestCase(), not in cleanup(). Add almost-duplicate
tests and clean up so that we now have {fail,skip}cleanup(,testcase}
tests to cover all four cases. Generated expected output. The new
tests (with old names) get their fail or skip - during cleanup() -
reported against the test instead of the cleanupTestCase function.
(Results for {init,cleanup}TestCase() are always reported, even when
these slots are not defined, as no-op passes.)
Pick-to: 6.4
Change-Id: I0988d1696b50c0e2f30c45ddc25e1bd0bfd2151a
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The call to metaObject() in the ctor may generate a warning since it
calls a virtual function during construction.
Amends be09628e15
Change-Id: I27472786b41624d582525c4260a54db61ee7ed16
Reviewed-by: Harald Sitter <sitter@kde.org>
Reviewed-by: Aleix Pol Gonzalez <aleixpol@kde.org>
Sending parent_window to the portal allows it/the window manager to
better place portal dialogs in respect to the application window, for example
on top of it instead of a random position. For this use the focusWindow()
(if available) since the API in QDesktopServices does not take a QWindow
parameter. The file dialog has an explicit parent that can be used.
The introduced virtual is provided as a hook for the wayland platform
that already includes a class that inherits from QGenericUnixServices.
Change-Id: I5571f08d07e5a4e3ae32efd1f09e2727cec9e7c5
Reviewed-by: David Edmundson <davidedmundson@kde.org>
It's perfectly possible to create static plugins in an otherwise shared
Qt build, but the logic to import these plugins into applications was
assuming a fully static Qt build. We now handle this more granularly.
Change-Id: Iacfa72f04c7918613b50ca87cf123e7f4c0841d5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Sanitizing the contents of the QTPLUGIN variable, and adding default
plugins from the available modules, should be a separate step before
the resulting QTPLUGIN is iterated and processed by for example linking
to each plugin, generating an import file, and adding module dependencies.
This makes it easier to add logic to the processing step later on.
Change-Id: I00e826c7fe87b29cf2e6bf4e1901c4d1482a20e6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The CMake build system files are properly generated, but the qmake parts
were missing.
Change-Id: Icbcce3143db976c536c802ea2314bc3f2595da51
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's perfectly possible to create static plugins in an otherwise shared
Qt build, but the logic to import these plugins into applications was
assuming a fully static Qt build. We now handle this more granularly.
This works for in-source tools and tests as well, which don't go through
the same CMake machinery for plugins as user projects do. The only case
that does not currently work is in-source examples, as they don't share
any of the plugin machinery with neither Qt internal tools/tests or user
project, but that's a bigger architectural issue that goes beyond this
change.
Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Window dragging has been considerably improved by replacing the mouse
events by pointer events and placing a pointer lock on WASM canvas, so
that off-browser window events are delivered to us.
Translation of the drag origin has been limited to inside the canvas, so
that a window cannot be dragged so far that it becomes offscreen and is
unreachable.
Change-Id: Id177c630a6466f04464a513371d6b97d3a098b6a
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Details: Added a note on how QProperty works in QML using BINDABLE keyword
Task-number: QTBUG-89166
Change-Id: Ib48dd26b0724f906efa65d14fbb75a8b97255b05
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It seems to be a hidden gem that one can stop redirecting the standard
output to a file without creating a new QProcess instance.
I have discovered this while browsing the private implementation of
QProcess trying to answer this question:
https://stackoverflow.com/a/72989131/2682142
I believe that this should be documented unless it is not meant to be
guaranteed behavior.
Change-Id: I180764d4cc56f6395d6d65942077e3ede63c71ea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Otherwise the errorString from qtls_openssl is lost that
would help a lot why a tls connection failed.
"Error during SSL handshake: error:1414D17A:SSL routines:tls12_check_peer_sigalg:wrong curve"
Pick-to: 6.4 6.3 6.2
Change-Id: Iab74b73488219686e5926308db02bc4063818c9f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
So long as you only ask us to copy it. Copying is mandatory, though.
I'll firm up the warning in a later commit, which may not get cherry-
picked as far back.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-105140
Change-Id: I3859764fed084846bcb0fffd170432abf65dc197
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This reverts commit 7b2ae3faab.
Reason for revert: this breaks multi-monitor XCB with HighDPI.
Fixes: QTBUG-105079
Pick-to: 6.4
Change-Id: I386c9480c33d1f67b3478332c8e03fe3eeeeee39
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Fushan Wen <qydwhotmail@gmail.com>
This patch improves the QT_INLINE_SINCE(maj, min) macro to take
deprecation version into account.
If the specified (maj, min) version is less than or equal to the
version defined by QT_DISABLE_DEPRECATED_BEFORE, the macro will expand
to "inline", and the out-of-line fallback will be removed from the
library.
This is achieved by introducing the helper
QT_IF_DEPRECATED_SINCE(major, minor, whenTrue, whenFalse) macro.
Fixes: QTBUG-104131
Pick-to: 6.4
Change-Id: I285029dad7b71126072b024a3be6d7b11341996d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Before a recent fix it would happen occasionally that
lastNormalizedPositions.at(0) would segfault because the list was
empty. The cause of the flakiness was fixed, but make the test more
resilient anyway by checking first the list is correctly populated.
Furthermore on some platforms this check fails:
qAbs(leftWidget.lastNormalizedPositions.at(1).x() - 0.8) < 0.05
So instead of QVERIFY use QCOMPARE_LT to print the values when it fails.
Task-number: QTBUG-104268
Change-Id: Id5430eb53c133cf5d23647cfd9749f01f266efce
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Sometimes XCB_EXPOSE event is being propagated twice, once before and
once after qWaitForWindowExposed(). But the window has focus only after
the second expose event. Changing it to qWaitForWindowActive() fixes the
issue.
Fixes: QTBUG-104268
Pick-to: 6.2 6.3 6.4
Change-Id: Ibc78dd4958ed1a4a8d0967b29d2a53457ab9ae8b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
the previous invocation wasn't working because QSpiAccessibleBridge
first needs to construct the connection before it can connect to the
enabledChanged signal that gets emitted as part of connectA11yBus,
effectively missing the signal emission because the connection wasn't
established by the time the emit happens. delay the signal emission
through the eventloop so the caller has time to connect to all signals.
https://bugs.kde.org/show_bug.cgi?id=452132
Change-Id: I1cf9fdd824b2c118cc6278b207aaaedeff259bb1
Reviewed-by: Aleix Pol Gonzalez <aleixpol@kde.org>
Add missing enum values in QPlatformTheme::standardPixmap to sync with
QStyle::standardPixmap changes from:
785d2b9d07aa5a595a98
Add enum values NStandardPixmap at the bottom of both enums as well
as an assertion in QStyle constructor that these values are identical.
Add omitvalue for NStandardPixmap in QStyle (QPlatformTheme enum is
not documented).
Pick-to: 6.4
Change-Id: I9ee528d032c445bed5aeace716893b2af8367de2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
ftdebug.c files are new, adapted the import script to copy the source
file for Windows as well.
Replaced the CMakeLists.txt content that was imported from the .pro file
with the respective variables and logic from the freetype CMakeLists.txt
file, which should make it easier to maintain this next time.
Pick-to: 6.4 6.3 6.2 5.15 5.12
Fixes: QTBUG-105032
Change-Id: I1e846167b268df4b1b0a50dcec602def1a0bdcb4
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We have deprecated the usage of Qt::MouseEventSource getter in
QMouseEvent::source() since 6.0. However, we have a lot of related
APIs, where the usage of this enum was not marked deprecated. Also we
have a lot of code in qtbase, qtdeclarative and some other modules
that rely on those values.
In most cases using QMouseEvent::source() is the only way to pass
the proper value to the other APIs.
This patch un-deprecates the method, so that we can safely identify
all of its usages in our code, and port away from it.
At the same time, we do not want the client code to use this method,
so documentation still mentions it as deprecated since 6.0.
Task-number: QTBUG-104857
Pick-to: 6.4 6.3 6.2
Change-Id: I767002aa6dc754fb5a58cf8fbf35774dae9986ed
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
And fix all the new warnings.
Task-number: QTBUG-104857
Pick-to: 6.4 6.3 6.2
Change-Id: I2a5791f495575d71d2344429aca3363f9922e31b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We deprecated QAction::setMenu(QMenu *) in Qt 6.0 because QAction needed
to become part of QtGui, and QMenu is a QtWidgets class. To keep
existing code working, we added a private API operating on QObject *,
and a template overload of setMenu, which allows callers to pass in and
get the object as a QMenu without any change to their code. The
implementation relies on a virtual function in QApplicationPrivate.
This solution might be as good as it gets. Making QAction operate only
on QObject* in the public API breaks exiting widget code, and it is
unlikely that we will come up with a QMenu abstraction that unifies
widgets and Quick UIs without breaking code either.
So, undeprecate the existing solution. If we come up with something
better, we can still deprecate it again in time for removing it in Qt 7.
Pick-to: 6.4 6.3 6.2
Change-Id: I1982b61feb1b1af99f4647e892c5fd74340d9c77
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
They are used in a lot of code, deprecating them now just creates noise
and porting effort without adding any value.
For Qt 7 we can remove them if we deprecate them in time for the last Qt
6 release, at which point porting effort is expected anway. Leave a ###
comment behind to that effect.
Pick-to: 6.4
Change-Id: I0a4e78cf1723b02373d23d7cd52783b3f7095428
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The QTextFormat::FontFamily enum is deprecated since Qt 6.0, however it
is still used in the code.
To retain backward compatibility with the old data stream formats, we
introduce a new internal QTextFormat::OldFontFamily enum value, which
has exactly the same value as QTextFormat::FontFamily, and use it
instead.
Task-number: QTBUG-104857
Pick-to: 6.4 6.3 6.2
Change-Id: Ibf5258b621c2b0aa507005dfe2c1e80c26ddb0d4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
And fix the usage that raised a deprecation warning.
As a drive-by: fix the deprecation declaration of QShortcut::id() to
use QT_DEPRECATED_VERSION_6_0 instead of pure Q_DECL_DEPRECATED.
Task-number: QTBUG-104857
Pick-to: 6.4 6.3 6.2
Change-Id: I5710127864909ce9352c7428e6aabbc89981b8f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@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>
When the method is wrapped into
if QT_DEPRECATED_SINCE(MAJ, MIN)
we also need to add QT_DEPRECATED_VERSION_[X_]_MAJ_MIN macro right in
front of the method declaraion, to actually trigger a deprecation
warning.
This patch does that for QCursor's deprecated methods, and fixes all
related compilation warnings in QtBase.
Task-number: QTBUG-104857
Pick-to: 6.4 6.3 6.2
Change-Id: Ic8d059e8c852d4b2dee55e7ea94f4fc7a402cdf4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
If the metatype does not support copy and default construction, then it
it unsuitunsuitable for use in QMetaType. We cannot prevent users from
passing in such metatypes (as we have e.g. a ctor taking QMetaType), so
verify this in customConstruct, and make the variant invalid in that
case.
Pick-to: 6.2 6.3 6.4
Change-Id: Ib1f0149c8fb9a1cce0049fd0311980754cc85d1b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Fix existing warnings by casting to the appropriate type.
Change-Id: Ic44d2a71e1a2e508199dbb46bea7a19e183ec42c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
On 32-bit platforms, the user can ask for more than INT_MAX bytes to
be returned from read(n), by way of its qint64 argument. We can, of
course, not return so much data because allocation would fail, so fail
early, by detecting this situation and do what resize() would have done
if it was not for the narrowing of its argument: throw bad_alloc.
Reviewers may ask themselves whether byteAmount(), which already caps
the request, would not have physically limited the request size to
INT_MAX, since we cannot possibly hold more data than that on 32-bit
platforms. But this is not correct, since QByteDataBuffer is
essentially a list of QByteArrays, and those can be shared copies of
each other (which isn't uncommon, if you consider how a user of the
class may be piecing together data by reusing existing QByteArrays).
The read(n) and readAll() functions are already documented to be
inefficient and should-not-use, we may want to remove them in the
future to force users to think about this problem in the context of
their domain.
Pick-to: 6.4
Change-Id: Ia152db0a1fc65bbef35acd463f12fba1b7726d4a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
