The code in qtdeclarative did not do anything at all anymore.
Change-Id: Idd97145cb74aeb4f43dfce2f282a765e90945073
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There may be a race where e.g. thread 'B' is woken up by a queued invoke.
At the same time thread 'A' asks 'B' to quit, which will set various
atomics (some important ones are 'interrupt' in the dispatcher and
'exit' in the event loop), but it does _not_ try to send another wake
since there is already an unhandled wake triggered by 'B' itself.
Sadly 'B' reads the 'exit' atomic before 'A' updates it.
Then, slightly before, 'B' sets 'interrupt' back to 0, 'A' write 1 to
it, meaning 'A's interrupt is ignored. Then, since there is no
interrupt, 'B' goes back to waiting for events, leaving the thread alive
and running instead of quitting.
Maybe this has unforeseen consequences (one consequence is that it will
return and re-enter the event dispatcher once more, possible
unnecessarily)
Fixes: QTBUG-91539
Pick-to: 6.1 6.0 5.15
Change-Id: Ie6f861f42ffddf4817d5c8af2d764abe9d9103c2
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There was a race condition in the test, since the window
might be exposed before the event to activate the
application has been received. And the short cut is not
triggered before the application is active, which
means it could just be discarded and the window would
never be closed.
This happened consistently when testing on Wayland.
Task-number: QTBUG-91418
Change-Id: I40cb143985175f5f2b5405e9502a48475c93074a
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
The test assumed that dialog.move() would actually move
the dialog box to the requested location, which is an invalid
assumption on Wayland.
Since the objective of the test is not to check if move() works
this way, but to check whether the dialog box shows up in the
same location when it is re-shown, we actually fetch the pos
after showing it the first time, rather than assume this is the
same as the requested one.
Task-number: QTBUG-91418
Change-Id: Ifa21fa08429f198988f90d7ee328e4f35a4764c2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
This test depends on XCB, but is only protected by a build-time
flag, so it will be executed as long as XCB is available at
build-time. Do as with the offscreen backend and just skip it
when a different platform plugin is in use.
Task-number: QTBUG-91418
Change-Id: Ida076dc81d0740af2cec164bd40ca10d16345f05
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
If the family name starts or ends with a space in the actual font
data, then this would not be selectable by Qt. This is because we trim
the family name before matching it against the contents of the database.
Testing on Windows GDI, it actually does trim the spaces on the
family names (matching a request for "Chibola" with a font called
"Chibola " for instance), but since we read the font data ourselves,
we are not doing this.
To ensure we never have font names that cannot be matched in the
database, we make sure we trim the family names before registering
them.
[ChangeLog][QtGui][Text] Fixed matching against fonts which has a
family name that ends or starts with a space.
Task-number: QTBUG-79140
Pick-to: 6.1
Pick-to: 6.0
Pick-to: 5.15
Change-Id: I9cdb50b78a7da2d2697f992ce462033eb1d7ada7
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Do what the Vulkan backend does, and just take the offset
and the QRhiBufferData. There is no reason to store a full
QRhiResourceUpdateBatchPrivate::BufferOp struct within the
backend.
Change-Id: I67528029de40320b3e4f031346d40dfc0bb9ab52
Pick-to: 6.1 6.0
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Follow the similar Vulkan change in 20eb40bce9
and drop the queued up buffer data for a given slot when the current update
covers the entire buffer. This is relevant in particular for Qt Quick 3D
where such dynamic buffer changes are common.
Change-Id: If1e70d78968586b552a5357bc97af10cc61d9611
Pick-to: 6.1 6.0
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Since qmake links against QtCore, we don't need to check for the
bootstrapping case in qlibraryinfo.cpp anymore.
Change-Id: I644b1e71db727773b3e32ac650481df134acf033
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Now that we're not actually using qmakeconfig.cpp anymore, we can remove
it together with all qmake-related information that was written into
qconfig.cpp.
This also moves the qtConfEntries array back to qlibraryinfo.cpp.
Change-Id: I5e57d8c55613332cc3e57b11df4398d46aed259b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Those have fixed values.
Change-Id: I7f1ba8036f43413d3c805f4b419ae79e037343fb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now, that qmake depends on QtCore, we can just ask QLibraryInfo for the
prefix instead of calculating it from QT_CONFIGURE_RELATIVE_PREFIX_PATH.
Remove that define.
Change-Id: I14be298a9d08abf33299e4cdbac55e91af318397
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is not configurable and doesn't have to be in the generated
q[make]config.cpp files.
Change-Id: If294d735800a3b5c6b3e269abdd86df401cf4864
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QIcon::detach can judgment if the d pointer is nullptr
Pick-to: 6.1
Change-Id: I90fd5f50ed2565a5654b978c4603635e62677953
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
If we only wait until the window is shown before testing the
event delivery, we may be getting a WindowActivation event
and subsequent paint event after we start testing. This can
cause a shift in the paint events, so that we end up with an
unexpected paint event at the end.
We should wait until the window is active before we start
checking the response to updates, to be sure nothing is pending
on the queue still.
Note that you'd expect QTest::qWaitForWindowActive() to do this,
but this actually falls back to qWaitForWindowExposed() when
the platform does not have WindowActivation capability. While
there is no real link between WindowActivation capability and
waiting for a window to be active, changing the behavior of that
function would be too scary, so we just implement an explicit
wait in the functions that depend on this.
Task-number: QTBUG-91418
Change-Id: Iee40dcfa1377f543ea05042cc5a972270b346708
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Since Qt 5.5, brush textures are stored as QImages. If the texture has
been set as a QPixmap, the conversion to QImage may change its pixel
format, depending on the native system format. That is acceptable.
Fixes: QTBUG-69193
Task-number: QTBUG-91418
Change-Id: Ic4dbeaa552b1f2183774a011e38414855a9dc4b1
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Includes both minimum deployment targets and minimum sdk
versions.
As per supported Apple platforms versions which was done
in qt/qtdoc at
8807fdedce29cbbd7662fcd745234da30eace3fb
For Qt for iOS 6.0.x we only bump the minimum
deloyment target because applications seem to crash with iOS 12.4+,
and it's better to have a build error than a runtime error.
The minimum required sdk will not be bumped for 6.0.x, so we don't
accidentally break someone's existing build, given that 6.0 is already
released.
Pick-to: 6.1
Task-number: QTCREATORBUG-23574
Change-Id: I3046384164f2d7fdbd0cfd16dcb85e0d60bc56ce
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Otherewise, we hit an assertion because the name is empty.
Fixes: QTBUG-91709
Pick-to: 6.0 6.1
Change-Id: I03a530d64ea8dead3efc5fcb8c00909388a387d0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Otherwise the benchmark crashes as the data tag for the row would be
empty.
Fixes: QTBUG-91708
Pick-to: 6.0 6.1
Change-Id: I484ded5b8670571b80012e64d67846d3b8db5320
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
...when it comes to the output size.
This mirrors what all other backends do. For example, with Vulkan
the only source of size is the surface (VkSurfaceKHR), never the
QWindow, even though we'd expect that the surface size equals
to window_size * dpr, and that's almost always true, but there
are exceptions. (e.g. we have seen bugs on Windows with some drivers
in high DPI situations where the Vulkan surface did not fully match
the window size, yet it is the surface, and only the surface, that
matters for rendering, i.e. viewports and such must match the surface,
not the native window)
With Metal we hit a similar problem on iOS: the QWindow's size*dpr
and what we calculate from the CAMetalLayer have a height difference
of 1.
Mitigate this by making QRhiSwapChain::surfacePixelSize() and the
calculation for currentPixelSize() done via the same route (the
CAMetalLayer). Otherwise, if there is a mismatch between what the
QWindow and the layer says, Qt Quick will think that there is a
resize happening (has happened) whenever starting a new frame, and that
has far reaching consequences (suboptimal performance, increased
memory usage by buffers, etc.)
Change-Id: I114df92bf35622c99f2747420fdce401db7705a6
Pick-to: 6.1 6.0
Fixes: QTBUG-91438
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If there is a large (3/5 of the screen in portrait or 2/3
in landscape) TextEdit on the screen, and it gets focus
on click, it will be shrank to fit the screen. Next click on this
TextEdit will restore its normal height, the next will shrink.
Pick-to: 5.15
Fixes: QTBUG-91056
Change-Id: I3dbf085cbfdc2739d537a304c16e28c58a6e01ce
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Associated changes in the qtdeclarative repo now ensure that arguments
for qml plugins are handled on the calling side. This reduces the
qml-specific logic needed in qtbase and gives qtdeclarative clearer
control over qml build and install locations.
As part of that work, the INSTALL_LOCATION keyword used in
qt_internal_record_rcc_object_files() has been renamed to
INSTALL_DIRECTORY to make it consistent with the keyword used for the
same concept in other commands.
Pick-to: 6.1
Change-Id: Iebd319899f63d79fbe15ce965b84ce324c28a508
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reformat a couple of examples correctly.
Change-Id: I2f0897267b4e3c4d7d2925f2d20cc45687278b0b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Features that are not emitted in the current
configuration (e.g. plugin-manifests on Linux) should not yield an
error. Instead, print a warning message like Qt5's configure did.
Set insignificant feature to OFF.
Remove the now unneeded emit_if parameter from
qt_feature_set_cache_value.
Pick-to: 6.1
Fixes: QTBUG-88305
Change-Id: I0f2ce152fca5f08417038c9bd2c07639ff6a3df4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
