Due to somewhat inverted logic introduced by the 8481a9fc97,
testing number of items in a pasteboard happens _before_ we fill it,
which is wrong and useless. As a result, maybeDragMultipleItems will
prevent the single item drag.
Pick-to: 5.15
Task-number: QTCREATORBUG-24665
Task-number: QTBUG-86786
Change-Id: Ia4be9fc56677575bb363cbb8b1adbea59e6c3b0b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Fix a logic error. QRegExp is a UserType in Qt 6 and we need to
check for it in the right place.
Fixes an autotest failure in the qregexp autotest in qt5compat.
Change-Id: I454cfcfd12b36f756b24b69a5412455db9dccbe7
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
Do not use QVariant::Type anymore, instead use QMetaType
For some reason, this pushed the qvariant autotest over the limit where
MSVC requires the /bigobj flag, so add that one.
[ChangeLog][QtCore][QMimeData] The signature of the virtual retrieveData()
function has changed and now takes a QMetaType instead of a QVariant::Type.
Change-Id: Ib46773bd731ee2177b1ef74d8162d744be7017ef
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We change the declaration of the new APIs using std::filesystem::path for
qdoc runs, and need to forward declare it consistently for qdoc builds to
avoid a flood of clang warnings when building documentation.
Change-Id: Iddcf0ce7d6207b6cc5910790315ab21076bd6ce1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
For documentation purposes, we treat QList, QByteArrayList, and QStringList as
simple classes, whereas reality is a bit more complicated. We conditionally
change the declaration of the types for qdoc runs, and need to be consistent
to avoid a flood of warnings from clang when building documentation.
Change-Id: I22d529079e10f8fd3d93edc771e5f05729fa925f
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Skip AUTOUIC on sources generated by the qt_add_dbus_interface and
qt_add_dbus_adaptor macros. Otherwise CMake will warn due to policy
CMP0071:
```
For compatibility, CMake is excluding the GENERATED source file(s):
(...)
from processing by AUTOMOC and AUTOUIC. (...)
```
Pick-to: 5.15
Change-Id: I7d14b23c9343940964d5bc0d1d18fc19b41b5cd0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
xcb-image includes xcb_aux.h, which is part of xcb-util.
Fixes: QTBUG-86287
Pick-to: 5.15
Change-Id: I253308008c5baeb1d061ef19f516ae6ab6dff52c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Resolve remaining Qt6 TODO
[ChangeLog][QtCore][QAbstractEventDispatcher] The signature of the abstract virtual registerTime function now takes a qint64 value for the interval parameter.
Change-Id: I10166ad5cfb455edc404d465a3731ff094a8977e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Current implementation of QProgressDialog always calls
QCoreApplication::processEvents() when the user calls
QProgressDialog::setValue() if the PD is modal. For most cases this is
fine, but when using a Qt::WindowModal PD with setValue() connected to
a signal in another thread using Qt::QueuedConnection a reentrancy
issue is present if setValue() is triggered too frequently as the
execution of its previous call may not have finished. If this happens
too many times in a row a stack overflow will occur.
Current documentation notes this potential issue but offers no way it
avoid it while still using QProgressDialog (user must implement a
custom dialog) without resorting to using Qt::BlockingQueuedConnection,
which unnecessarily reduces performance.
Introduces the boolean reentrancy guard "processingEvents" that is
checked before calling QCoreApplication::processEvents() in a modal
PD when setValue() is used. It is set before the first call to
processEvents() and cleared after that call returns. This ensures that
only one invocation of processEvents() is possible from within
setValue() at a time, and thereby minimizes iterations of the main event
loop and eliminates the aforementioned stack overflow condition.
See - https://forum.qt.io/topic/118292/
Fixes: QTBUG-10561
Pick-to: 5.15
Change-Id: Ifa9b91cbb66881981356954ead0906bdc91fab60
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
As a build tool, qmake should produce deterministic outputs.
Pick-to: 5.15
Task-number: QTBUG-86675
Change-Id: Ifc855d6ddf025cdad3aa57aee79beabf9c6008e2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
bistream-vera is not a known license for SPDX. Instead use a DejaCode
URN. Handling of such URN's is done in a separate patch in qtools.
Pick-to: 5.15
Change-Id: I687507ab05d2d377a50dbc0a1037071a9de68341
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
QDirIterator is documented to be non-deterministic.
Fixes: QTBUG-86675
Pick-to: 5.15
Change-Id: I4161871a409bbaf85347ee6a60ef1189f56a1b22
Reviewed-by: hjk <hjk@qt.io>
As can be seen in the _q_resolveEntryAndCreateLegacyEngine_recursive method
in QFileSystemEngine, paths starting with ':' are treated as QResources,
which means that from QFileInfo's POV they're "not relative", which is why
QDir::isAbsolutePath would return true.
Pick-to: 5.15 5.12
Change-Id: I701d08ce43ea707bc34c928e39bea0b83597a4b6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In order to modify a container through an iterable, we need the original
container to be mutable. The iterable, then, is not a conversion of the
container, but rather a view on the container. The concept may be
extended to other types.
In order to facilitate this, provide a set of methods in QMetaType and
QVariant similar to the convert family. The new methods are non-const
and expect the original value to stay available during the life time of
the view.
Change-Id: I363621033f7fc600edcea2acb786820ccba49c86
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
And add mutable iterators. This requires some refactoring of the
existing iterators.
Task-number: QTBUG-81716
Change-Id: I61b3a3e8c0df5fd449679257a29d9f0c3d19c4f0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This will enable run-time debugging on Windows, using
_CRTDBG_MAP_MALLOC, which uses #define to override the
standard library memory management functions, including
realloc.
Fixes: QTBUG-86395
Change-Id: I51975dd74cab0ae8309436c86d17a59074c561e1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The constructor taking an array literal will now stop at the first
null-terminator encountered.
And fromArray is introduced which only supports array literals.
Constructs a view of the full size. Explicit so it shouldn't be
surprising.
Change-Id: I1497c33a5c12453a95e87c990abe6335b2817081
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
1. Make the ctor unable to construct a QByteArrayView from
array literals other than 'char'.
With the new behavior it would either be (very likely) unintended to
pass e.g. a std::byte array to the ctor. And it would be confusing
because you would get different sizes based on signed-ness.
2. Introduce fromArray
Only supports array literals. Constructs a view of the full size.
Explicit so it shouldn't be surprising.
Change-Id: Ifdb55eb21057dfe7053b2561bd81e2c9825e9bc6
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
For HTTP connections, QNAM defaults to opening its TCP socket in
unbuffered mode. This means that Qt will send the data written
into the socket right to the kernel, queueing only if the kernel
says it doesn't want more data for the moment being.
QNAM itself then uses separate write() calls to write the HTTP
headers and the body of the request (like POST or PUT). These 2+
writes result in headers and body being sent over different TCP
segments -- even if, in principle, a POST with a few bytes of data
(e.g. a HTML form, or a REST or SOAP request) could fit in the same
segment as the request.
Multiple writes like this interact extremely poorly with other
TCP features, e.g. delayed ACKs, Nagle's algorithm and the like.
In a typical scenario, the kernel will send a segment containing just
the headers, wait for the ACK (which may be delayed), and only then
send the body (it wasn't sent before because Nagle was blocking it).
The reply at this point is immediate (because the server can process
the request and starts replying), but the delayed ACK is typically
40-50ms, and documented up to 500ms (!). If one uses QNAM to access a
service, this introduces unacceptable latency.
These multiple writes to the OS should be avoided.
The first thing that comes into mind is to use buffered sockets.
Now, there are good reasons to keep the socket unbuffered, so we
don't want to change that. But the deal breaker is that even buffered
sockets won't help in general: for instance, on Windows, a buffered
write will immediately detect that the socket is ready for write and
flush the buffer right away (not 100% sure of why this is necessary;
basically, after populating the QTcpSocket write buffer, Qt enables
a write socket notifier on the socket -- notifier that fires
synchronously and immediately, without even returning to the event
loop, and that causes the write buffer flush).
Linux of course offers the perfect solution: corking the socket via
TCP_CORK, which tells the kernel not to send the data right away but
to buffer it up to a timeout (or when the option gets disabled
again, whichever comes first). It's explicitly designed to support
the case of sending headers followed by something like a
sendfile(2). Setting this socket option moves the problem to
the kernel and we could happily keep issuing multiple writes.
Ça va sans dire, no other OS supports that option or any other
similar option.
We have therefore to deal with this in userspace: don't write in the
socket multiple times, but try and coalesce the write of the headers
with the writing of the data. This patch implements that, by storing
the headers and sending them together with the very first chunk of
data. If the data is small enough, this sends the entire request
in one TCP segment.
Interestingly enough, QNAM has a call setting TCP_NODELAY
currently commented out because Qt doesn't combine "HTTP requests"
(whatever that means). The call comes all the way back
from pre-public history (before 2011) (!). This patch doesn't
touch it.
Fixes: QTBUG-41907
Change-Id: Id555d14e0702c9f75c3134b18277692eb3659afe
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
That XML was parsed over and over again, because the QMimeXMLProvider
was re-created instead of re-used.
Pick-to: 5.15
Change-Id: I07ff005d3f238afc1490b69a58cf4815e67d418c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Qt Quick Pointer Handlers depend on this behavior:
QQuickPointerHandler::onGrabChanged() receives only the grabber that
was losing the grab or the one that is receiving it, not both at the
same time. UngrabExclusive means the original grabber simply
relinquished the grab by setting the exclusive grabber to null.
CancelGrabExclusive means the new grabber took over the grab that the
old grabber had before.
Task-number: QTBUG-86729
Change-Id: Iefca6fe91b11fcb03d2c6ac3598841c924facb22
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The recently added check to avoid negative-bitshift ub ignored that
the algorithm will sometimes use a negative bitcount value as a
flag. This caused reading failure for some frames.
Pick-to: 5.15 5.12
Fixes: QTBUG-86702
Change-Id: I4c247a7eb6102f9b51cc8ac708c60db80d609e38
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Any but the last /MERGE:from=to option passed to QMAKE_LFLAGS was
ignored. Now, the first options gets a <MergeSections> tag and all
further options are added as AdditionalOptions, because vcxproj files /
the VS property editor do not support multiple MergeSections entries.
Pick-to: 5.15
Fixes: QTBUG-86062
Change-Id: I65bddf0b8c7ed6c162008d6ad1b58c2aba2d07d9
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We must use the LIBRT location instead of LIBRT_FOUND which is not set anywhere.
I failed to replace this one in my previous patch.
Change-Id: I6e2df82c31e29018d99afec1eecfb80a321fddd4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The documentation for [NSWindow performWindowDragWithEvent:] only
mentions mouse-down events, but starting a drag from move and drag
events works too, so include them as well.
Pick-to: 5.15
Fixes: QTBUG-85105
Change-Id: Ib6c29ed4035bfccc61d50a7f95f564fb3d56fcf6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Check the reference count before deleting. Patch
as contributed on bug report.
Pick-to: 5.15 5.12
Fixes: QTBUG-86547
Change-Id: I2cb197e3eeda7ade2442c23f6b4f1ae6ff2ff810
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This makes it easier to know which values to use in BLACKLIST files
for a flaky test, for example.
Pick-to: 5.15
Change-Id: I12af99d68f97e016aa42be9ae9d70de5fc0a58ed
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Utility for visualizing and debugging high-dpi rendering
using QPainter, at different (fractional) scale factors.
In addition contains prototype code for mitigating
painting artifacts such as drawing outside the clip
rect when scaling.
Change-Id: I44f39315ad9674790d51413dddf41e3a51043da6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
DprGadget displays the devicePixelRatio for the current
screen using a large friendly font, as well as the
platform and environment inputs used for determining
the DPR.
Change-Id: Id619edad181eb7717f18eb98af341d6582a843a1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Simplified the logic around reconciling hour12, ampm and hour in the process.
Mindless coding-style tidy-up.
Change-Id: I0b7cabc57539d0d7201fef33e0120b84f4bb4994
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Updated QFuture docs to be more precise about QtFuture::Launch::Sync
policy.
Change-Id: Ic267c71f858e04a47ea1fc0996ea342d5eae7744
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In fact, this variable can take only two values: 0 and 1. By
interpreting its value as boolean, we can use relaxed store operations
instead of atomic increments. This is safe, because it's guarded by
'activateEventNotifiersPosted' variable, which already provides a
release/acquire semantic.
Change-Id: If9adb7d022f1500ee7e8b61f336d8732f9b88d4c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
[ChangeLog][QtCore][QByteArray] QByteArray is a prepend optimized
container similar to QList.
Task-number: QTBUG-84320
Change-Id: I45ed1cb75414930f5998be58bfcfe343b1790331
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
As OpenGL ES and Vulkan ruin the day with the spec mandated minimum
value for max threads per threadgroup being only 128, clients need
a way to decide if their compute shader (local_size_*) is suitable
for use at run time.
Change-Id: I72b4fc97032406340623add82ea4d9544ebe9fdc
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The recently introduced overflow check for 8 bit images was too
aggressive, causing the last pixel on each line to be rejected.
As a driveby, add the same (fixed) overflow check also for 32bit
images.
Pick-to: 5.15 5.12
Fixes: QTBUG-86691
Change-Id: I62e4d5884e314f1171cb5a3e2c48657ce7259676
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This code, after applying it to linguist, didn't compile.
Change-Id: I25011a44ca059a149f041f8f07848232883140cc
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
After we started defaulting to high-dpi enabled, it was discovered
that it does not work correctly with the placeholder screen. Since
the placeholder screen has no physical size, and the default
implementation of logicalDpi() divides by the physical size, we
got a scale factor of NaN in the high-dpi code.
The effect of this was that the nooutput test in Qt Wayland would
fail, because it did not get the events it was expecting, since
the window geometry was never set to a valid rect in the
resize() call.
Task-number: QTBUG-86698
Change-Id: I7ee68db9a13446b414502ae0f26fd214531c673a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The non-deprecated one called the deprecated one :-(
Inline the deprecated one and simplify, given the null pointer passed down.
Change-Id: I5b99053357fc3be109e61ccf1161835bf527b686
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The reason for this bug is that after the TextItem loses focus,
the focusItem in QGraphicsScene is already empty.
When QGraphicsScene responds to the inputMethodEvent event again,
since focusItem is already empty,focusItem will no longer deliver events.
Fixes:QTBUG-85088
Pick-to:5.15
Change-Id: I329054333c2adec133d35318761612aca3afcf0d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Use QVERIFY in test functions, and (void)tr.load outside.
Change-Id: I18d2eb3aeaf00f9f2bbe75d0a2d8b12569b541e1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
