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>
The function uses external non-cache variable that is set in different
cmake macro. It's better to pass the value as argument.
Pick-to: 6.5 6.6 6.7
Change-Id: I282bd506cf2dcd998a0ddd7deaad244fab34a8db
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We are already including the 'DejaVu' font, which is a
further development of Vera and includes the same glyphs.
Change-Id: I2eb58967751101489158ecbf268102a72b9b2bea
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@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>
Replace some more string-based connects with pmf-style to trigger a
compiler error instead a runtime error if a signal or slot does no
longer exists.
Pick-to: 6.7
Change-Id: Ibc047cc935885a30ea58367fa97e9f962b87ca2c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
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>
That is, don't call QByteArray::data() because that one is still under
QT5_NULL_STRINGS conditional. Instead, like QString, call d.data()
directly, which is allowed to return a null pointer.
This necessitated a fix to QStringBuilder's QConcatenable because it was
iterating from &QByteArray::_empty to nullptr.
[ChangeLog][Important Behavior Changes] Calling begin() or end() in a
const QByteArray will return a null pointer if isNull() is true. This is
the same behavior as QString. This is important for code attempting to
iterate from data() to end() instead of begin() to end().
Change-Id: Ica7a43f6147b49c187ccfffd179e4cda75bd1031
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
In the case of QString, the vast majority of searches are case-
sensitive, so by inlining we make the user code call qustrchr() directly
instead of QtPrivate::findString(). In the case of QByteArray, the call
is to memchr(), which being a compiler intrinsic, may itself be inlined
or even just resolved at compile time.
In both cases, a great deal of searches use from=0.
Benchmark for QByteArray; before:
8.83207052 nsecs per iteration
22.01568546 CPU cycles per iteration, 2.49 GHz
60.00000331 instructions per iteration, 2.725 instr/cycle
21.00000281 branch instructions per iteration, 2.38 G/sec
After:
6.42561493 nsecs per iteration
16.01623130 CPU cycles per iteration, 2.49 GHz
49.00000261 instructions per iteration, 3.059 instr/cycle
18.00000211 branch instructions per iteration, 2.8 G/sec
This shaves 6 cycles in the execution and 11 instructions (3 of which
were branches), slightly improving the IPC raito, for the QByteArray
case. For QByteArrayView, there are 2 fewer instructions (1 a branch),
but the number of cycles is the same at 16.
Task-number: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e2204ebb6a348
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
QByteArray::indexOf() had the best implementation of the two *because*
it was out-of-line, in qbytearray.cpp. The compiler could thus see the
body of the QtPrivate::findByteArray() function and inline it, with
constant-propagation, so only findCharHelper() was expanded and we had a
fast path towards memchr().
On the other hand, QByteArrayView::indexOf() was inline, so the
compiler emitted the call to QtPrivate::findByteArray() in user code,
causing the full function to be executed. We fix that by adding a char
overload for QtPrivate::findByteArray() and lastIndexOf(), so we get to
memchr() more quickly.
Also, inline QByteArray::indexOf() and lastIndexOf().
Before:
QByteArray::indexOf():
8.83287376 nsecs per iteration
22.01766832 CPU cycles per iteration, 2.49 GHz
62.00000330 instructions per iteration, 2.816 instr/cycle
21.00000281 branch instructions per iteration, 2.38 G/sec
QByteArrayView::indexOf():
9.64034694 nsecs per iteration
24.03001151 CPU cycles per iteration, 2.49 GHz
68.00000355 instructions per iteration, 2.830 instr/cycle
23.00000306 branch instructions per iteration, 2.39 G/sec
After (same result for both, requires recompilation):
8.83207052 nsecs per iteration
22.01568546 CPU cycles per iteration, 2.49 GHz
60.00000331 instructions per iteration, 2.725 instr/cycle
21.00000281 branch instructions per iteration, 2.38 G/sec
The inlining appears to have cut 2 instructions, but the effect is not
measurable in this benchmark (the entire code is in cache and the Branch
Predictor is probably primed).
Fixes: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e1cb4b306fc62
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This is a repeat of the last commit, which did the same for QByteArray.
No benchmarks in this commit, assuming the results are similar (at least
for cs = Qt::CaseSensitive).
Task-number: QTBUG-119750
Change-Id: Ica7a43f6147b49c187ccfffd179e1f852272af8b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Amends e608bc0192 by adding the
implementation of this method whose implementation got accidentally
removed (because it became unused). It's added in removed_api.cpp
because, as the commit said, the cost for creating an empty
QAnyStringView is practically nil.
It's not zero on Windows, because the replacement function has five
parameters, so the last (the options) is passed on the stack. But that
is not enough of a justification to keep separate functions.
Pick-to: 6.7
Fixes: QTBUG-120309
Change-Id: I6e2677aad2ab45759db2fffd17a29b4ec7728426
Reviewed-by: Rym Bouabid <rym.bouabid@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@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>
* Added icons to the controller.
* Keep the car within the scene.
* Removed the ui file because 4 buttons can be maintained in code easier.
Change-Id: I10af821beb442939e1e7fbdd3ffbde67a272bb2f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The snippets in the QStylePlugin class documentation show the
relevant bits well enough.
Pick-to: 6.7 6.6
Fixes: QTBUG-119974
Change-Id: Iba4a37664d64d86a2946f41d131a201ccdcd723b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
.qmlextra's text color #254117 is too dark. Let it inherit a better
suited text color.
Amends: 436467134e
Pick-to: 6.7 6.6 6.5
Fixes: QTCREATORBUG-30117
Change-Id: Ia9e0567b0b00f2e7c1359ac85f10c72cece3c087
Reviewed-by: hjk <hjk@qt.io>
- Update screenshot
- Provide some information text on the screen when no images are found
- Add all supported image formats to the file filters
- Minor fixes according to our coding conventions: eg. don't shadow
variables
Fixes: QTBUG-119979
Pick-to: 6.7
Change-Id: If41adf34f38bfa101f2c5433082828c1a10668b1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In Qt versions greater than 6.4.2, when using Qt:FramelessWindowHint and
WS_THICKFRAME simultaneously, and handling the WM_NCCALCSIZE message to
draw a frameless window, the right and bottom sides may extend beyond
the drawable boundaries.
This is because in the previous commits, the calculation for margins was
skipped for windows with Qt:FramelessWindowHint set. This is correct for
non-maximized windows. However, when a window is maximized on Windows,
its actual size is slightly larger than the drawable area to avoid users
from dragging the border to resize the window. When window was maximized
, the code for calculating geometry should remove the margins instead of
skipping its calculation.
The fixed code determines whether to skip the calculation of margins and
frame by checking whether the window is maximized during the calculation
[ChangeLog][QPA][Windows] Adding a check for the maximized state of the
window during the calculation of margins. Margins calculation will not
be skipped for maximized windows.
Task-number: QTBUG-120196
Pick-to: 6.7 6.6 6.5
Change-Id: I63c8dbc8f65ff28cc581be261acfd3f675b027c4
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Prioritize CMake snippets.
* Remove unrelated mention to various qmake variables.
* Mention the page for command line configuration and building
and remove the same duplicated command from this page.
* Mention the page for customizing the build from the Android docs.
Task-number: QTBUG-115020
Pick-to: 6.7
Change-Id: I966c37661e17f6ffb8d25bfa3cd91e92be364e1d
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
A QT_MESSAGE_PATTERN including %{backtrace depth=4} should give
the call site of the QScopedScopeLevelCounter.
Task-number: QTBUG-120124
Change-Id: Ie477994882bde9168c931479102017ad5fde426a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The activated signal is delivered as a queued connection, so we're
going to raise the scope level as part of notifyInternal2() anyways.
In addition, since c5d4972577 we will
automatically raise the level to 1 due to the catch all logic, so
in case the connection is changed to direct connection, we'll still
raise the scope level as needed.
This removes the last remaining QScopedScopeLevelCounter outside
of QtCore.
Task-number: QTBUG-120124
Change-Id: I91a8ab8c1969d2209657daaca5c232928d1dd985
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
9da8d67b3b has commented out setting the
current index of the combo box container during a mouse hover event.
That has caused a regression.
Amend the patch and enable visual hover effect.
Fixes: QTBUG-120167
Pick-to: 6.7
Change-Id: Ic12e70f9f70ac2f7b9604580562c35551659c5e2
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This allows other areas to utilize this
Change-Id: I4bc7e8374289a19afe8b639b2b3b0dc0f8f65a3a
Done-with: Mikolaj.Boc@qt.io
Reviewed-by: Morten Johan Sørvig <morten.sorvig@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>
There's two alternative strategies for fixing this:
1. When fetching the preferred sizes from an item, the number is bounded
to a smaller (but still very large) value - not subject to overflow.
In practice this will result in the correct layout, but the
consequence is a small inconsistency: The preferred size of the
layout will be less than infinite despite that one of its items have
a preferred size of infinite.
2. Do not bound the fetched preferred sizes from items, but instead
let the rest of the code handle infinity.
This will result in the correct layout, and also a correct preferred
size of the layout.
This patch uses the second strategy, by applying a bound when needed.
Autotest will be submitted to qtdeclarative, since QGraphicsLayouts are
not affected by this.
Pick-to: 6.7 6.6 6.5 6.2
Task-number: QTBUG-116577
Change-Id: I49f79d288370bd93831ac9eda623ce4bbf587796
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Turn on anti-aliasing, and update screenshot.
The example is still not great and under-documented, but at least it
doesn't look horrible anymore.
Pick-to: 6.7 6.6
Task-number: QTBUG-120291
Change-Id: Ie709cb51d64c535d7cd0aa1451b3c5bb901324cb
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>
showNewMessageBox() shows an "old" message box, if a default button
argument was passed and the buttons argument doesn't contain a default
button. It passed the int value of defaultButton to showOldMessageBox,
where it was interpreted as a normal button.
The StandardButton::Default flag was not set on the default button.
This relied on the QDialogButtonBox owned by QMessageBox to show the
expected default button by co-incidence. As this was not always the
case, tst_QMessageBox::staticSourceCompat() even tested wrong expected
results.
=> Add the Default flag to the default button, before passing it as an
int value.
=> As a drive-by,
- replace c-style casting with static casting.
- add braces to multi-line if clause.
Task-number: QTBUG-118489
Pick-to: 6.7 6.6 6.5
Change-Id: I9cf93c8f93d6ab80e7be5ab25e56bc59d3d6209c
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>
Setting a DefaultProperty is arguably something
more useful to people than the 'made up' version example.
Also add more links to the relevant QML pages.
Pick-to: 6.6 6.7
Change-Id: Id967df7ddf81511299f95b9fd24f56af671fb855
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
The function is given a vector of Http2::Frame's and flattens it into
a vector<uchar>. While each Frame can contain a maximum of 16GiB of
data (24-bit size field), one "only" needs 257 of them to overflow the
quint32 variable's range.
So make sure any overflow does not go undetected.
Keep the limited uint32_t range for now, as we don't know whether all
consumers of the result can deal with more than 4GiB of data.
Since all these frames must be in memory, this cannot overflow in
practice on 32-bit machines.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: Iafaa7d1c870cba9100e75065db11d95934f86213
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The essence of the example was already fully quoted in the
model/view documentation. Move the code into a snippet
source, and update the screenshot.
Fixes: QTBUG-119976
Pick-to: 6.7 6.6
Change-Id: Id2f10bb26a650419969bbfa9b76cb74babd3319e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
Otheriwse Qt C++ code will not be able to find it.
Task-number: QTBUG-115016
Pick-to: 6.7
Change-Id: Id3a2efb1f33cb60a523359e1ad646a394e24397e
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Janne Juntunen <janne.juntunen@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Ville Voutilainen
Alexey Edelev
Lorn Potter
Morten Sørvig
Assam Boudjelthia
Axel Spoerl
Christian Ehrlicher
Thiago Macieira
Matthias Rauter
Volker Hilsheimer
Jarkko Koivikko
Alessandro Portale
Doris Verria
Yansheng Zhu
Lucie Gérard
Tor Arne Vestbø
Jan Arve Sæther
Anu Aliyas
Kai Köhne
Santhosh Kumar
Marc Mutz