Make toMimeDataWithFile() handle writing files to the
in-memory file system correctly: this is an async operation
and we need to collect the files as the writes complete
and then invoke the callback once all files have been
saved. There's then no need for a global static QMimeData.
Use toMimeDataWithFile() for both the paste and drop
handling, however QPlatformClipboard::setMimeData() takes
ownership of the passed in QMimeData and the callback API
must be designed accordingly.
An open question is when we should delete the files.
Deleting them right away (after calling the app event
handler) is predictable, however it looks like QPlatformClipboard::setMimeData() retains the current
QMimeData until a new one is set, so maybe we should
follow that.
Pick-to: 6.7
Change-Id: Ia9b825eaef1134ff9a554e51ee7e41d1c2ee779a
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
QScopedScopeLevelCounter was added and it doesn't really need
threads to function, but apps fail to link without it.
Change-Id: I7b355369079bc11b8b8b45b3ee1bf5ba81cd1953
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
Also means these mapping can now also handle overflowing perspective
better.
Pick-to: 6.7
Change-Id: Id506634c445521f1b041ec2e9051aa499c24671b
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Use QString as inheader record as the place of definition of both
Qt::Literals and Qt::Literals::StringLiterals. Previously mentioned
headers never exist.
Fixes: QTBUG-120379
Pick-to: 6.5 6.6 6.7
Change-Id: I104f73b338a144ef5f296500a9a4368cd3791750
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
Q_TESTLIB_PRIVATE_EXPORT is the redefinition of Q_TESTLIB_EXPORT.
Keeping the both makes no sense.
Task-number: QTBUG-117983
Change-Id: Id909530f1453ad092a45f40c1c85fed1f66e38d7
Reviewed-by: Jason McDonald <macadder1@gmail.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The devicePixelRatio was not taken into account when a standard icon was
requested from the windows qpa which resulted in blurry icons for a
dpr != 1.
Therefore pass the dpr-corrected size to QWindowsTheme::standardPixmap()
and pass this size to SHDefExtractIcon() to get a correctly scaled icon.
Pick-to: 6.7 6.6
Fixes: QTBUG-52622
Change-Id: Ia771dd2f93fa133cf2c4429ef59a9c5cb05ad047
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
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>
Shawn Rutledge
Morten Sørvig
Lorn Potter
Łukasz Matysiak
Allan Sandfeld Jensen
Alexey Edelev
Rami Potinkara
Assam Boudjelthia
Christian Ehrlicher
Ahmad Samir
Tomasz Kozlowski
Ville Voutilainen
Axel Spoerl
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