To make sure qmake generates appropriate rules when building other
applications.
Task-number: QTBUG-84781
Change-Id: I75618575602be820bf20a8067e3a6ee3ff7e7950
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qtremoteobjects has a tool that uses qt_process_qlalr. The function
doesn't have a check to see if the consuming target is an imported
target, to skip doing any work when corss compiling.
Fix it, like we do in qt_extend_target.
Change-Id: Ide389a371aa07225f08689d15125c04d8b0e3916
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
- stop using deprecated accessors in QTabletEvent and QMouseEvent
- position() and globalPosition() provide high resolution so
we don't need to display hi-res global pos separately
- keep a pointer to the last-seen QPointingDevice instance
rather than copying fields out of it; it will only be deleted
if the platform plugin does that (usually only at exit or
when it's unplugged)
- show seat ID
- show platform-specific device ID
Change-Id: Ic34e1d1256d6956867992db831c2e66bdda7001e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
There was a decision to use QList consistently in public API, now that
it's supposed to perform as well as QVector. Amends
6589f2ed0c
Task-number: QTBUG-46412
Task-number: QTBUG-72167
Change-Id: I30004792667ee0581a433409ac2e20ffc645e952
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@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>
QWidget::screen() was added in b455a863a1
and this is another good use for it (in 5.15 and newer).
Amends c068edcecf
Pick-to: 5.15
Fixes: QTCREATORBUG-24195
Task-number: QTBUG-76162
Change-Id: Ifaafe9b45fafaae220da54bbf3bc7a568e7953f9
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Since commit e343affd63 we're creating object libraries for Qt
resources in static libraries. Those must be reflected in the
generated .prl files for static builds of Qt.
In qt_add_resource, we now calculate the install locations of the
object files of rcc-generated C++ files and save them in the target
property QT_RCC_OBJECTS. This property is then passed to
QtFinishPrlFile to write the object file paths to the .prl file.
Change-Id: Ic383892d723d02fc91f712bc2dbcbc90babad074
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We do not support building with qmake from the build directory in prefix
builds. Therefore we can just use the standard QT_INSTALL_LIBS property
instead of the /get variant.
Change-Id: I82ccaf1894fb1dccc9ec18b4984b582b555ce0f8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since commit e343affd63 we're creating object libraries for Qt
resources in static libraries when building Qt or a Qt-based project
with CMake. The purpose of this is to remove the need for calling
Q_INIT_RESOURCE in static libraries.
Add a note to the documentation and a changelog entry.
[ChangeLog][CMake] Calling Q_INIT_RESOURCE in static libraries is not
strictly necessary anymore for CMake-based projects. There, for each
resource, an object library is created which is linked into consuming
projects. This ensures that the linker does not discard the resource's
object file, and its initializer is called automatically.
Change-Id: I70de439f964dc7257a2255683eda4d434fa451d0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is needed as a preperation for introducing QByteArrayView, which
will use qsizetype instead of int for size. Since these methods will be
reused by QByteArrayView, they need to use qsizetype.
Change-Id: Ia2d94ec70742d4f9326de9548fd7534d56d3a5ac
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Warn about using an invalid type id in all cases. So far, only some
constructors of QVariant would warn. Move the warning over to
the place where we map a typeid to a QMetaTypeInterface to catch all
cases.
Change-Id: I4cd48a2b5d6c597dbf2afbeae9b811cd0819b768
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
And inline the copy constructor forwarding to another one.
Change-Id: I3c4f76f7b14edd84f512ef0687416b20940e333a
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
When the base platform theme is not set to a null pointer, then we might
assume it has been already constructed and later on try to access an
invalid address which will cause a crash.
Pick-to: 5.15
Change-Id: I6187336bca527e1feeb0902bcfb16f2fbec86d24
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Remove the DirectWrite1,2 features. Windows 10
should have them, only MinGW is missing directwrite3.
The feature directwrite now implies DirectWrite2.
- Remove the custom defines.
- Port over the configure tests from configure.json
and add missing ones for DirectWrite(2), DirectWrite3
and Direct2D and Direct2D 1.1, fix the conditions
and report them in the summary.
Task-number: QTBUG-83255
Fixes: QTBUG-83931
Change-Id: I1fc68997adc715bd5c6d7ec457f58c46e1f81c6a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A lot of qtdeclarative tests fail due to not finding the
QtTest qml plugin in ${prefix}/qml. This is just the symptom, the
problem is that the combination of CMake + MinGW + Qt relocatability
behaves incorrectly.
The value returned by
QLibraryInfo::location(QLibraryInfo::Qml2ImportsPath) for the
qmltestrunner executable is ${prefix}/bin/qml which is incorrect.
This happens due to a combination of things. The
c33916a279 change in qtbase introduced
checks to figure out whether an application is a windeployqt-ed app
to adjust the prefix path.
This check tries to find the import library libQt6Core.a in the lib
subfolder whenever the executed app dir path is equal to the
computed prefix path.
If it's found, the code assumes we are running a tool in
${prefix}/bin. If it's not found, the code assumes it's a
windeployqt'ed app, where the Qt .dlls are next to the executable.
Currently when QtCore is built with CMake targeting MinGW, we actually
create a libQt6Core.dll file instead of a Qt6Core.dll file, and also
an import library called libQt6Core.dll.a, instead of libQt6Core.a.
The prefix check code actually prepends an additional "lib", thus
trying to find the liblibQt6Core.a import library.
This fails, the code assumes a windeployqt'ed app, and returns the
currently executed app path dir as the prefix aka ${prefix}/bin in
the case of qmltestrunner, and thus none of the qml plugins are found.
To fix this, generated the shared library and the import library names
as qmake expects them, aka Qt6Core.dll and libQt6Core.a.
Some of this renaming was done for MinGW plugins and shared libraries,
but not for modules in 9b0e23ef8a.
Extract the duplicate code and apply it to all shared libraries built
by Qt on Windows. Adjust the prefix and suffix accordingly, depending
on whether we use MinGW or not.
Amends 9b0e23ef8a
Task-number: QTBUG-84886
Change-Id: I5a8618597df5f57ce256739adced3f24eb13dac7
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The change fixes the labels to show up correctly in the configure
summary.
It also allows enabling the sanitizer via the feature flags, e.g.
-DFEATURE_sanitize_address=ON.
Finally the qtbase sanitizer option is saved in QtBuildInternalsExtra
so that repos built after qtbase have the same sanitizer options
enabled.
Change-Id: Ic9d9e3ce3c7ebbc244ced2e6d163d1ac8ee06b12
Fixes: QTBUG-84721
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The QPair changes trigger warnings about size_t vs. quint32.
We made offsets and sizes 32-bit in the QRhi API to emphasize that
some of the graphics APIs are using 32-bit sizes still. It's a bit
unfortunate that pairs now generate warnings when the size does not
match. Just cast as needed.
Change-Id: I88504eed8be6f4bdb2205b3671e2c2a9db9fcb1e
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The Vulkan spec changed the behavior for VkApplicationInfo::apiVersion
in 1.1, conveniently breaking compatibility with all existing 1.0 logic.
We can no longer assume that the 1.0 behavior, which was failing instance
creation with VK_ERROR_INCOMPATIBLE_DRIVER for an unsupported version,
is always in place. So do not rely on this in the test, and add a
reminder in QVulkanInstance docs as well.
Fixes: QTBUG-85040
Change-Id: I8f5c7a7830877b72d106c444aebfaea191083ee0
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Indicate that doing a QRhiResourceUpdateBatch::readBackTexture() for
texture formats other than RGBA/BGRA is not necessarily supported at
run time.
Change-Id: Ie9ca9546a3af9bff142b875f1ecf26bf26bcc442
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The connectivity pre-check has been around for a long time, and it has
caused various issues in that time. Certain scenarios, like using
certain VPN configurations, might confuse the OS into thinking you don't
have and network connectivity at all and abort the connection.
Especially noticeable/frustrating when the connection was going to a
host inside the local network.
The negative impact of this change would at worst be that we might try
to connect and it will wait some amount of time before the OS tells us
the connection failed in situations where it would previously have been
aborted before it started. But the false-negatives are not really an OK
sacrifice in that case.
Fixes: QTBUG-84907
Change-Id: I37fc69051e39df3c1a1fecb56ef54521a4d3d0c3
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
They are justified in using huge memory.
Pick-to: 5.15
Change-Id: Id16d2ea67cfac0e031d05258173391e222b41097
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Note for manual testing: You can read it manually with vo+shift+h
Fixes: QTBUG-84864
Pick-to: 5.15
Change-Id: I5686e40642396db2fde685cf07b758acd29c6ee0
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Remove the warning message that was introduced in 84f2792597.
It is triggered for debug_and_release projects that are built against
a single-configuration Qt. Silently fall back to the behavior before
84f2792597 like it always was the case.
Change-Id: I67ed1a145ec5d7a4047b0ce5ad43bf0fc6834d60
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
To successfully link plugins of a static Qt build into a Qt project we
need to generate .prl files for the plugins.
Task-number: QTBUG-84781
Change-Id: I1406052f2269050aa7cbe6aa2b546bece1c68467
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This function is only used on FreeBSD and Linux.
forkfd.c:243:12: warning: unused function 'convertForkfdWaitFlagsToWaitFlags' [-Wunused-function]
Pick-To: 5.15
Change-Id: I99ab0f318b1c43b89888fffd160bf81f01960f2f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
In qmake land the define is set in mkspecs/common/macx.conf which
means it should be public for all Qt consumer apps as well, not just
internal targets. Make it so.
Amends 17be43c58e
Task-number: QTBUG-83929
Change-Id: I9f9d7dfca24b54977cb8364723c3618d3fec2e73
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The large file flags in qmake land are set in the
mkspecs/features/unix/largefile.prf file, which is loaded by qmake
when a CONFIG += largefile entry is written by configure into
qmodule.pri.
This essentially makes them global flags for all private Qt targets
because qmodule.pri is a global file loaded load(qt_build_config)
Thus assign the flags onto the PlatformCommonInternal target instead
of the PlatformModuleInternal one.
One peculiarity though is that in qmake land these flags are also
applied when building examples as part of the main Qt build. This
is because qt_build_config loads qmodule.pri even for an example,
because qmake sees it as part of the overall Qt build.
The flags are not applied by qmake if the example is built in
a different standalone build dir not part of the Qt buil dir.
We don't do that in the CMake build, and thus examples will never
have those flags.
Task-number: QTBUG-83929
Change-Id: If653a669b4835aadd1de84acb477c375ab523909
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The qt_internal_apply_gc_binaries function should apply both compile
and link flags, not just link flags.
The flags should be applied publically to all consumers of Bootstrap
regardless if the gc_binaries feature is enabled.
The flags should be applied publically to Core only in case if the
feature is enabled (aka for static builds only).
Change-Id: Id42af0d9b527004d74c04eff2c9e3c2be1e76aac
Fixes: QTBUG-84461
Task-number: QTBUG-83929
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This mirrors what qt_tool.prf does.
Task-number: QTBUG-83929
Change-Id: I892a3f5f62d461456abfa414718fcc4c4c05c012
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Add misisng namespace bits.
The example is built by a CMake configuration.
It is not built in a qmake configuration due to a missing
x11 / embedded requirement.
Task-number: QTBUG-84881
Change-Id: I6c53299a53e7c4e19d994ec2ae2d542667d41899
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
CL = Content-Length
The uploadByteDevice was kept after a redirect which caused the
internals to assume that we had to upload the data. Even if this was
not the case we still transmitted the Content-Length header from the
first request which was now stored in two places.
Fixes: QTBUG-84162
Pick-to: 5.15
Change-Id: Ic86b1ef0766ffcc50beeed96c1c915b721d40209
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It was removed but some documentation bits were still there, apologies
Change-Id: I1888b34fe04e6566349d35a27391d0bd14d622d4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
