This test is resizing window, which is not supported in EGLFS,
so it needs to be skipped.
Pick-to: 6.7
Task-number: QTBUG-115777
Change-Id: Ie136f6565b4d466bc62c4e2ebe2337488b5003b4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
getOpenGileContent() takes a parent now, and the compat
API is behind a QT_WIDGETS_REMOVED_SINCE(6, 7) which
the manual tests can't access.
Pick-to: 6.7
Change-Id: I81784baed178bb8efd1a848d32c9ee4510971e26
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Verify that the file is saved correctly to the local
file system by loading it and printing the sha1 of
its contents.
Also add indents in order to improve legibility. The
output lines should now be correctly nested.
Pick-to: 6.7
Change-Id: I698c016253656aef29f04129da5f01a9dc35191e
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The docs claim that QThreadPool always creates at least one thread.
However, the user can (usually by mistake) request zero or a negative
number of threads.
The maxThreadCount() function is simply returning the value, that was
requested by the user.
Since it's a public API, it is used in several places in QtConcurrent,
where it is assumed that the value is always positive. This can lead
to a crash if the user sets zero as a maxThreadCount.
Update all such places with std::max(maxThreadCount(), 1).
Prefer this approach over changing the return value of
maxThreadCount(), because its behavior is documented and tested.
Amends 885eff0537.
Fixes: QTBUG-120335
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: Id3b2087cec7fbc7a2d42febca6586f2dacffe444
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The pdf testing relies on the sips tool in macOS to render generated
pdfs into pngs. In recent macOS updates, that tool has changed
behavior, and no longer produces the desired output. Fix this by using
a custom pdf page size, instead of relying on cropping behavior in
sips.
Pick-to: 6.7 6.6 6.5
Change-Id: I9b2e947424774bb4456a6aefe04288b84401a9b7
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The UBSan raises a division by zero in getRadialGradientValues. This can
be avoided by calculating the inverse in
qt_fetch_radial_gradient_template as a checker is done to avoid
division by zero there. (Credit to OSS-Fuzz)
Pick-to: 6.7
Fixes: QTBUG-120332
Change-Id: I798d1efc87ee07df7ca6f401aa476013cdbffe42
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Remove dead code (since at least Qt5.0) - does not work and is
bitrotting since ages.
Change-Id: Ieb34e42137bc40c4edea47656b153a47f0ae34cd
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This test was disabled during Qt5 porting because it was unstable.
According to the discussion in the bug report, a deprecated function was
used to wait for the window to get exposed. This was later replaced by a
more robust QTest::qWaitForWindowExposed() but the test was not
re-enabled again.
Pick-to: 6.7
Fixes: QTBUG-22544
Change-Id: I3190e38c1f42dc719803a60e66a86c3773cbedcd
Reviewed-by: David Faure <david.faure@kdab.com>
Some platforms like VxWorks do not support inotify
or any similar solution for file watching.
Because of that, the implementation falls back to polling.
That means that tests that require a native backend will fail.
Fix the problem by skipping adding a test case for a native backend.
Task-number: QTBUG-115777
Pick-to: 6.7
Change-Id: I0d683e6376a0453bd2fd591302c4f3ef7ceea87c
Reviewed-by: Pasi Petäjäjärvi <pasi.petajajarvi@qt.io>
The default value in the default manifest has been for few
releases, set as minimal, and since Widgets Android style
is not fully supported anymore, we can set this to default
to minimal under the hood as well to avoid needing to always
explicitly needing to set it to minimal.
Pick-to: 6.7
Change-Id: Id0b2134c572694be1e190347ff75f51ade65f0c4
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
An assert is harder to miss than a warning, which makes it more likely
to get fixed. Thanks to Mårten Nordheim for the idea.
Add the assert in inline code so that users compiling their code in
debug mode (or with -DQT_FORCE_ASSERTS) can hit the assert even when
built agaist a release build of Qt (not everyone compile their code with
a debug build of Qt). Thanks to Giuseppe D'Angelo for the idea.
Pick-to: 6.7 6.6 6.5
Task-number: QTBUG-115125
Change-Id: I2935d32ea5a2c288d7a836abbae66ac53cb5ab2f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This test is resizing top window, which is not supported in EGLFS,
so this test needs to be turned off.
Pick-to: 6.7
Task-number: QTBUG-115777
Change-Id: Idb81802399fe5bd9af3f342692d2212cd06ead9c
Reviewed-by: Pasi Petäjäjärvi <pasi.petajajarvi@qt.io>
The test manages to completely lock up our Linux ARM64 machines.
Task-number: QTBUG-119321
Change-Id: I7c36095d14e47ac0660f18ea07af7a04ec7688fb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tero Heikkinen <tero.heikkinen@qt.io>
QPlainTextEditPrivate::updatePlaceholderVisibility() issued a full
viewport update, when the document became empty and the placeholder text
needed to be shown. No update was issued, when the placeholder text was
replaced by a first text character entered.
That relied on the assumption, that the placeholder text would disappear
with the first text line being rendered (even if it has just one char).
When the placeholder text covered multiple line, only the first of them
disappeared.
This patch adds a boolean to remember, that the placeholder text is
shown. If that is the case and the first char is entered, a full update
is issued, to remove all lines of the placeholder text. The boolean flag
is cleared thereafter, to avoid unnecessary viewport updates.
isPlaceHolderTextVisible() is renamed into placeHolderTextToBeShown(),
because the method returns an instruction, rather than a state.
tst_QPlainTextEdit::placeholderVisibility() is adapted to test the
boolean flag, hence the real visibility of the placeholder text.
That extends its scope to the bug at hand.
Fixes: QTBUG-119808
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: I07a7059ae619dc85d0c21247d829120e6afa7115
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Commit ba5db13c8d ("QStringView: add
internal qToStringViewIgnoringNull()") said:
As long as a null QString still returns non-null data(), QStringView's
QString constructor needs to call isNull(). That's a branch we often
can do without, so add an internal function that bypasses this
correctness check.
It's internal, since we might have a Q6String that returns nullptr
data() when null, which will remove the need for this function.
For Qt 6, we made QString and QByteArray be able to return nullptr from
data() when null... but that's not enabled by default yet. However, the
begin() functions do return nullptr, so we can avoid the extra branch
the commit was talking about.
Task-number: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e4cf032bc8565
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Embedding a QWidget in a window container (via its windowHandle())
may cause crashes, e.g. during drag & drop and when the application
goes out of scope.
If a QWidget->windowHandle() is attempted to be embedded in a window
container, return the pointer to the widget instead of creating a
container.
Add an autotest.
Update documentation.
[ChangeLog][QtWidgets][QWindowContainer] If createWindowContainer()
is called with a QWidgetWindow argument, return pointer to the
widget instead of new container.
Pick-to: 6.7
Fixes: QTBUG-119113
Change-Id: Id052a03be13adce05bbd025d86270d265dfb662e
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
If a widget received a DragEnter event that it didn't accept, then the
UnderMouse widget attribute gets set. But the drag manager never got a
drag target, so the DragLeave event was never delivered, leaving the
UnderMouse attribute set incorrectly.
We always need to send DragLeave events to the receiver, even if the
DragEnter or DragMove was not accepted. Otherwise we are not in balance,
and the UnderMouse attribute will remain set.
This is a change of behavior and a very old bug, so only fixing this in
unreleased branches. Test case added to verify that explicitly generated
drag events result in the correct enter/leave events.
[ChangeLog][QtWidgets][QWidget] DragLeave events are now always sent to
the widget the mouse is leaving, even if it didn't accept the DragEnter
event.
Fixes: QTBUG-50403
Pick-to: 6.7
Change-Id: I5eae49da000fb4fea81f1767f0e73a06a6b78975
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
QDialogButtonBox::layoutButtons() rebuilds the focus chain based on the
button layout. It relied on the fact that the last button in the layout
would point back to the first button. That is not the case, if
- a focus frame gets inserted in the chain, and
- the default button is not at the layout's first (=left) position.
In that case, the chain stops at the button left of the default button.
The default button can not be reached by tabbing forward. Back-tabbing
still worked.
By not "closing" the focus chain, the focus proxy was set to the first
button found in the layout. That is wrong, whenever the default button
is not at the first layout position. When the box got focus for the
first time, pressing "Enter" could lead to a non-default button being
triggered. A Yes/No message box would have No as its default button.
On Linux, it would pop up with "No" being highlighted, but "Yes" having
focus. Pressing Enter would trigger Yes, instead of No.
tst_QMessageBox::staticSourceCompat() heuristically defines the
button expected to be triggered by Enter. On Linux/KDE, it would pass,
when the wrong button was fired.
=> Always "close" the focus chain, by linking the last and first
buttons.
=> Make the default button the button box's focus proxy.
=> Change tst_QMessageBox::staticSourceCompat() to always expect No
being fired by Enter in a Yes/No box.
[ChangeLog][QtWidgets][QDialogButtonBox] Default button becomes
focus proxy of a QDialogButtonBox. This ensures that Enter triggers
the default button, instead of the first button in the layout.
Fixes: QTBUG-118489
Pick-to: 6.7 6.6 6.5
Change-Id: Ic626d3d0fe7ba8b924c21734332e98532f11c80e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The test function casts QMessageBox::StandardButton variables to
integers, to pass them as arguments and verify expected buttons.
In case of a test failure, this makes it hard to figure out, why a test
was failing.
Add a local macro to cast int values back to the enum before calling
qCompare(). That way the enum keys will be displayed in the logs.
Task-number: QTBUG-118489
Pick-to: 6.7 6.6 6.5
Change-Id: I23e766d5026cff3e4775db56e58f808809709e4c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The test was flaky, because of qWaitForWindowActive() after show().
It is not guaranteed, that a window has focus after show().
Use qWaitForWindowExposed() instead.
Task-number: QTBUG-118489
Pick-to: 6.7 6.6 6.5
Change-Id: I1eb8a73f2beafec00c4a6f6b34bfd36a8d6e4d93
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The adjustment of block length with 'off-by-one' affects content
length during undo operation. The issue occurs when we perform undo
operation for a set of group blocks that have same fragment
position. Since their positions are same, group block change
(QTextDocumentPrivate::documentChange) with respect to insertion
doesn't affect document block length and further adjustment to
'off-by-one' without considering this leads to incorrect document
content change information (such as invalid information with regard
to characters removed).
This patch skips adjustment of group block length during undo
operation.
Amends 8fbedf2196
Fixes: QTBUG-113865
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: I315dcf01ba5b2f4ed6d95e9d6910d82848374aef
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
A call to QWidget::destroy() will end up in QWindow::destroy(), which
calls QWindow::setVisible(false).
A call to QWindow::setVisible(false) on a widget's window will under
normal circumstances end up in QWidgetPrivate::setVisible(), which in
turn recurses back into QWindowPrivate::setVisible(), via
QWidgetPrivate::hide_helper(), ensuring that the QWindow internal
state is updated, visibleChanged emitted, and show/hide events sent.
Durin QWidget::destroy() we end up in QWindow::destroy(), which calls
QWindow::setVisible(false), but in this case the widget no longer has
Qt::WA_WState_Created, so the hide_helper() call is skipped, and the
corresponding QWindow is not kept in the loop.
To work around this we could have checked for windowHandle() instead
of Qt::WA_WState_Created before calling hide_helper(), but that had
many other side effects, so we opt for a more targeted fix.
Pick-to: 6.7 6.6 6.5
Change-Id: I68f80e5f7df9ee811afcd274a7ee4de31a110da5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
If there's e.g. an infinite loop during main() that
would previously result in a blank page, but not error
message. The expected case is that we would get a RangeError
exception, but that exception never reaches the catch
handlers in qtloader.js.
Work around this by setting noInitialRun, followed by
calling main manually. We then need to handle the case
where the app.exec() workaround throws, which should
not trigger an error.
Pick-to: 6.7
Change-Id: Ia8431279308770981316cd168e4316341bfb2531
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Add test for making network request via Emscripten Fetch API on
main and background thread.
Task-number: QTBUG-118225
Change-Id: I7c3923493818e75a5c16e4e5f553a69cb1438c44
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Both the GUI and core version of that test is flaky on QNX.
Pick-to: 6.7 6.6
Task-number: QTBUG-119359
Change-Id: Ied7013e04bdd12270a84ab32d2bd4e45c52136c3
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Mandated by P0792R9 already, but we never checked and P0792R14 has
user-defaulted assignment operators showing up in the synopsis now,
so make sure we don't accidentally break this going forward.
Amends 29b65c98e7.
Pick-to: 6.7 6.6 6.5
Change-Id: Ief9c5ff30895f8bfccec1c24d1777d3dab76c95a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The tool tip content size uses an incorrect content margin, when it's
constructed. This content margin has been reset to correct value when
tool tip is positioned using placeTip(). But after that, the content
size not been recalculated.
This patch triggers updatesSize() to calculate content size with
updated content margin values.
Fixes: QTBUG-119752
Pick-to: 6.7 6.6 6.5
Change-Id: I454c8528505686f2724b897e4002f78f3049149a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We used to look through the event queue in QCoreApplication::postEvent,
and if we found an existing DeferredDelete event for the receiver we
would compress the two events into one.
This was changed in 99b89d30fa, as the
logic was causing O(n^2) for deleteLater, by using one of the bits
in QObjectData to track whether the object had already been deleted.
But it kept the logic for tracking this in QCoreApplication::postEvent,
and QCoreApplication::compressEvent would still do the work of deleting
the additional QDeferredDeleteEvents.
To avoid the unnecessary heap allocation of the QDeferredDeleteEvents
we can move the debouncing/compression to QObject::deleteLater().
We use the same mutex as in QCoreApplication::postEvent to guard
concurrent access to deleteLaterCalled.
A note has been added about the (preexisting) issue that the mutex
is not sufficient to prevent data races, as the deleteLaterCalled
flag is part of a bit-field, and we're not guarding any of our
other accesses to other bits.
As QDeferredDeleteEvents is private API, we can rely on no-one else
posting it than QObject::deleteLater(), which should be the case now
that tst_QApplication::sendPostedEvents() was fixed.
The documentation has been clarified as well. It's safe to call
deleteLater() more than once, but that's not _because_ other
pending events for the object are cleared. The latter behavior
is normal ~QObject() behavior. The documentation was probably
written at a point we didn't do any event compression at all
for QDeferredDeleteEvents.
Task-number: QTBUG-120124
Task-number: QTBUG-119918
Change-Id: I2a733095b7cb066ba494b1335aa40200c749cb0c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The example uses QTreeWidget when it should use a QTreeView with a
dedicated item model, primarily shows how to use item views (and very
little about QSettings), and is generally not useful to show how an
application could or should use QSettings to store settings.
Turn it into a manual test instead; it's useful for that as it supports
ini and plist files, and settings in different scopes.
Pick-to: 6.7
Fixes: QTBUG-119978
Change-Id: I7ce039f6391c41c679d126d90a251eee60327c39
Reviewed-by: Ed Cooke <ed.cooke@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Some sub-classes have special handling of source model layout changes
(abbreviated as SMLC from here on out), they relied on disconnecting the
connections to the _q_*layout* slots in the private class using the SLOT
macro. This isn't possible any more after recent changes (and the method
were renamed to remove _q_ prefix).
Sub-classes resorting to using private API is a clear sign some
functionality is missing from the public API, so a cleaner solution for
this issue is adding this setter which enables sub-classes to tell
QIdentityProxyModel to leave handling of the SMLC to them. Thanks to
David Faure for the idea/solution.
[ChangeLog][QtCore][QIdentityProxyModel] Added
setHandleSourceLayoutChanges(bool) method to allow sub-classes to
indicate to QIdentityProxyModel that they will handle source model
layout changes on their own. Also added a getter,
isHandleSourceLayoutChanges().
Change-Id: I1de79dd693ce32a6e2df9a7c81dd4abdc5f00248
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Because we may be able to use the other side's storage and apply the
operation in-place. We reuse the storage of the one that can be
detached: even if we have to grow the buffer, QBitArrays are usually
small so there's a good chance it's just to the extra space QArrayData
usually overallocates or a simple, non-moving realloc().
Disassembly with GCC 13 and Clang 17 show the vectorisers did kick in
for all four functions (inverted_inplace included). I think a
hand-rolled version could squeeze a few more cycles, especially in the
tail section, but I don't consider its maintenance cost to be worth it.
Pick-to: 6.7
Change-Id: I85b3fc2dd45c4693be13fffd1795bfb1b296caa6
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
A copy without pixel ratio was made, but color table not set.
Pick-to: 6.7 6.6 6.5 6.2
Fixes: QTBUG-119902
Change-Id: I328f3faa70d7a1263061cbe51921999393e30801
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
If the commit of data to a model index result in that index getting
filtered out, then the editor will be removed as part of committing the
data, and the index that the editor is associated with becomes invalid.
The subsequent call to closeEditor() will find that the index for the
editor is no longer valid.
This should not warn, and it should also not abort the clean-up process
early. Instead, identify that the editor that we want to closed is
already hidden. In that case, skip the warning and most of the cleanup
process, and proceed directly to the EndEditHint handling further down.
Add a test that simulates the two scenarios where this can happen:
either the committing of data results in the index being filtered out
by the existing filter; or the filter changes while editing, and the
index being edited gets removed. In both cases, we don't want to see a
warning, and the state of the item view should be reset correctly.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-115765
Change-Id: If247172fdac9a1a9279dae96c078d32553d4ee5d
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
When using QKeySequence::DeleteEndOfWord or
QKeySequence::DeleteStartOfWord in a QLineEdit with an existing
selection, the selection was ignored which resulted in unexpected
behavior (see bugreport). This is fixed by only setting the selection
if none exists yet.
To prevent an entry in the history when the input is empty, the
selection is checked before calling del().
Fixes: QTBUG-120006
Pick-to: 6.7 6.6 6.5
Change-Id: I2e803c5eff1f0e289e93a77c58ecd78299241da7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
A splash screen is usually shown during initialization, before the main
window is shown. At that point, an application might not spin an event
loop. The documentation therefore recommends to run processEvents()
periodically, in order to ensure that the splash screen is actually
shown. Async window managers (e.g. XCB) might require more than one call
to processEvents() for the splash screen to be shown. It can't be
guaranteed, that a specific number of calls to processEvents() make the
splash screen visible. Calls to processEvents() are not considered
good practice in application code.
QSplashScreen::finish() uses a copy of QTest::qWaitForWindowExposed(),
to automatically close the splash screen, when the main window is
shown.
=> Re-write the static inline waitForWindowExposed to wait for the
widget's windowHandle()->isVisible(). That ensures visibility to the
window system.
The previous version waited for isExposed() to become true. That
ensured exposure to the application, but not visibility.
=> Intercept QEvent::Show and process events, until the splash screen
becomes visible.
=> Remove references to processEvents() as a requirement to show the
splash screen from the documentation. It remains a requirement for
processing mouse and keyboard events.
=> Re-activate tst_QSplashScreen and test visibility in the constructor
test function.
Drive by:
- implement switch in event override
- factor out paint event handling in a function
- update documentation about calling processEvents() to enable mouse
handling.
Fixes: QTBUG-119225
Pick-to: 6.7 6.6 6.5
Change-Id: I07910705246b4e3234e01cc4896f5bc4b2c56772
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The example has a lot of code and documentation, but in essence shows
how to use float-based QPainter APIs and how to set a render hint. That
is two lines of code, which we can show as snippets.
Update the screenshot of the example with a higher-resolution version.
Pick-to: 6.7 6.6
Fixes: QTBUG-119983
Change-Id: Iafcb813dff6ab8c269176f7994c95947ebf5e559
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
It was forgotten when we originally fixed the hardcoded 1_1 version.
Pick-to: 6.7 6.6 6.5
Change-Id: Iff3148d79466dac2830fe9a63d954aead96fb0ac
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This patch replaces the QBasicFutureWatcher that was used for
continuations with context objects with a smaller QObject-based wrapper
that works directly from the actual continuation.
The idea stays the same: In order to run continuations in the thread of
a context object, we offload the continuation invocation to the
signal-slot mechanism.
Previously, we've hooked into QFuture with QFutureCallOutInterface to
emit a signal and trigger continuation invocation. However, it is much
easier and robust to emit that signal from the continuation itself.
This sidesteps the locking issues that QFutureCallOutInterface handling
presents. QFutureCallOutInterface basically requires any consumer to
only access the QFuture after all events have been posted and the
internal mutex unlocked, i.e. on the next cycle of the event loop.
Continuations do not impose this restriction; runContinuation()
explicitly unlocks the internal mutex before calling the continuation.
This fixes a deadlock when using QFuture::then(context, ...) where
the paren future is resolved from the same thread that the context
object lives in.
Fixes: QTBUG-119406
Fixes: QTBUG-119103
Fixes: QTBUG-117918
Fixes: QTBUG-119579
Fixes: QTBUG-119810
Pick-to: 6.7 6.6
Change-Id: I112b16024cde6b6ee0e4d8127392864b813df5bc
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
There is no need for {}, and removing them resolves the warning.
Change-Id: Id9812a9ba328f03839dd953662a82b05f99b0b8b
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Amends 32edae5e26, after which we keep a
copy of the restored state if the state couldn't be applied yet. Since
making a copy of the entire state results in multiple copies of layout
item pointers, we might end up with dangling pointers if the layout
structure is modified while we keep the copy. This can happen if methods
such as tabifyDockWidgets or splitDockWidget get called; e.g. tabifying
dock widgets will destroy the layout items that were added for them.
Unfortunately, the layout items do not have a pointer back to the layout
they live in, and the items in the stored state might not yet live in a
layout anyway. So we cannot remove the items from their layout in a
QDockWidgetItem destructor implementation.
Instead, we have to forget the stored state. Add a helper function that
writes the stored state back to the actual state, and deletes the stored
state afterwards. Call this function when the layout might get modified
programmatically.
Add a test case that reproduces the crash without the fix, and passes
with the patch.
Fixes: QTBUG-120025
Pick-to: 6.7 6.6 6.5
Change-Id: I8f7e886f3c4ac38e25f9b8bc194eea0833e5974f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
... instead of just choosing the closest scaling factor.
Otherwise we end up with the 1x pixmap for a 1.25 scaling factor instead
of a the better fitting 2x pixmap.
Task-number: QTBUG-90634
Change-Id: Ic554fc8d2715deea43bc22e71414902a263b2fef
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Now that the assignment-bitwise operators can reuse storage, we can make
these operators also be capable of reusing storage.
Pick-to: 6.7
Change-Id: I85b3fc2dd45c4693be13fffd1795b893de65a5b8
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Instead of creating a temporary copy of one of the two sides (which will
share QByteArray), create one with the correct target size such that it
is already detached.
Drive-by move them to hidden friends.
Pick-to: 6.7
Change-Id: I85b3fc2dd45c4693be13fffd1795b74eeaf3be71
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Makes it possible to add new unpremultiplied formats later.
Change-Id: Id998a2674ca9067a0e2a5f85c7baf04bcd9a9912
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
No functional change, yet. Just dissociating the data name from type
name, so we can add tests for FP types in a follow-up step.
Pick-to: 6.7 6.6 6.5
Change-Id: I98fdebb49cca614ab27db146c4bacafd190e7d9b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
std::string is a nice value_type for when you want to track short
strings (because of its SSO). Check that it works, incl. in case
the implementation falls back to QSet in the absence of std::pmr
support in the stdlib.
Pick-to: 6.7 6.6 6.5
Change-Id: I2406258355295c2b1300c4ae8001cead59bb27d6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Tomasz Kozłowski
Morten Sørvig
Ivan Solovev
Eirik Aavitsland
Hatem ElKharashy
Christian Ehrlicher
Łukasz Matysiak
Assam Boudjelthia
Ahmad Samir
Ville Voutilainen
Axel Spoerl
Thiago Macieira
Volker Hilsheimer
Kai Köhne
Santhosh Kumar
Tor Arne Vestbø
Doris Verria
Piotr Wierciński
Marc Mutz
Allan Sandfeld Jensen
Johannes Grunenberg
Mårten Nordheim
Arno Rehn
Amir Masoud Abdol
David Schulz