The loops don't change the m_connections container. The call chain is:
- registerObjectPeer() unittest constructs a MyServer, which connects
QDBusServer::newConnection to MyServer::handleConnection(), the
latter stores each new connection's name in m_connections
- An QTestEventLoop is entered, which triggers handleConnection(),
handleConnection() calls exitLoop() at the bottom (this is repeated
multiple times)
- server.unregisterObject() is called, iterating over m_connections
- server.registerObject() is called iterating over m_connections
- between the unregisterObject() call and the registerObject() calls
m_connections is not modified AFAICS
Thus no need for taking a copy of m_connections (not that it matters
much, it's a QStringList with size() == 3).
Change-Id: Idaea2ca4d3b27fc88d39f8434e3817a2a4098c72
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Straightforward, the code was already iterating over a local const
copy, i.e. Q_FOREACH wasn't needed here.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I3e806c54ce56b6eb06431eea6aea1758c8ecd154
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Amends f2f8820073.
I have no idea how this went through the CI, but assigning to a const
variable cannot possibly compile.
Reported-by: Axel Spoerl <axel.spoerl@qt.io>
Pick-to: 6.6 6.5
Task-nubmber: QTBUG-115839
Change-Id: I0f22dcd5ab691f92880ea3c6446aedca53df0721
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Commit 9db5ca87897340873a4606c651a37e0356e8f1a0 sets the default
qtDataDirectory to the value of qtInstallDirectory, which results in an
invalid path when appended to the SDK. This results in build failures
for Android when building with qbs. cmake builds are not affected as
the data directory is explicitly set in the build scripts.
Pick-to: 6.6 6.5
Change-Id: Ia29c5bae7648f5fccefe019c225e187985bd2592
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We need to apply properties of the QWindow the underlying "native
window", in this case our <div>, on construction, without waiting
for the user to call one of the QWindow setters.
Pick-to: 6.6
Change-Id: Id422a9424f584e2269ef333e2c7c88a123ecb70b
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Only top level windows should have window manager features,
to match other platforms.
Pick-to: 6.6
Change-Id: I7a0563ef34aeb430d0b1a16633a5626482ccd17d
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
A child window should be possible to place at arbitrary positions
within its parent, even outside the parent's current rect. Once
the parent size is changed, the child might become visible.
The current code also caused issues when the parent did not
have a size yet (0x0) at the time of the child's setGeometry
call, resulting in the child always being placed at y=0.
Pick-to: 6.6
Change-Id: I1534b606ab6eb7d51216d3b305a1b60443c41ec2
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
For offscreen frames this is a significant improvement since
now we will have timings available after endOffscreenFrame()
returns, meaning the behavior matches the Vulkan, D3D12,
and Metal backends in this regard.
It also enables getting timings in frames that have
QRhi::finish() or QRhiCommandBuffer::begin/endExternal()
calls.
Change-Id: I1cc45a47e7215f342df0b1c600cc481088c8135b
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Another one in the series of problems around having texture-based and
regular widgets in hierarchies where some widgets are native and some
are not.
Pick-to: 6.6 6.5
Fixes: QTBUG-115652
Task-number: QTBUG-108344
Task-number: QTBUG-113557
Change-Id: I34306503cb17ccb915b90168ec3f39e209f668e5
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Extended linear Display P3 + FP16 is likely the thing to use
on platforms such as VisionOS and iOS (and optionally on macOS)
and perhaps iOS). Enable testing this on macOS with the hdr
manual test.
Change-Id: I67f0bdbadae8c7ebccae7de008f12fd8d9135529
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Pass an encoded URI string before parsing them through the Android APIs.
Fixes: QTBUG-114435
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I65131799fad81bfe7490d663d3b7996c94d37f0b
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
A subinfo has its own item list. Recurse into it when debugging.
Task-number: QTBUG-115058
Pick-to: 6.6 6.5
Change-Id: Ide820e4440caa97b84a3366c2d385546fb6026ec
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The method calls show() on a dock widget group window, when the window
flags have changed. When all of its contained, tabbed dock widgets are
programmatically hidden or docked on the main window, an empty group
window is shown.
This patch implements bool hasVisibleDockWidgets(). It returns true, if
at least one of the group window's dockwidget children is not hidden.
It replaces show() by setVisible(), passing the return value of
hasVisibleChildren().
It adapts tst_QDockWidget::floatingTabs() to test the fix.
(Drive-by: remove dead code)
Fixes: QTBUG-115058
Pick-to: 6.6 6.5 6.2
Change-Id: Ifb8e2450e91a7c78decc06f592e160631ca2faf5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The method reads the next element in a loop, as long as valid elements
exist. Within the loop, it returns
- false if the end of an element has been reached
- true if a new element has started
When the document end has been reached, the loop continues, until
readNext() returns Invalid. Then, PrematureEndOfDocumentError is launched.
This is wrong, because reading beyond the document end is caused by a
missing return condition in the loop.
=> Treat document end like element end and return false without
reading beyond it.
=> Test correct behavior in tst_QXmlStream::readNextStartElement()
Fixes: QTBUG-25944
Pick-to: 6.6 6.5 6.2
Change-Id: I0160b65880756a2be541e9f55dc79557fcb1f09f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By actually registering them.
Commit 850d850c5a changed from
qMetaTypeId<QDBusArgument>() to QMetaType::fromType<QDBusArgument>() and
in Qt 6, fromType() does not register the type with the database. That
means the lines became runtime no-ops at that time or during the
QMetaType updates since 6.0. All they did was instantiate the C++ inline
variable.
The testing also detected we didn't register QList<QDBusVariant> as an
alias for the "av" signature. I'm not entirely sure you're allowed to
use this because QtDBus does not like re-registration of the built-in
types, and "av" is already assigned to QVariantList. This is no trouble
for the parser, anyway.
Minor change to qdbuscpp2xml to allow reading from stdin, so we don't
have to create temporary files.
Pick-to: 6.5 6.6
Fixes: QTBUG-115964
Change-Id: I80612a7d275c41f1baf0fffd177a14925e7d23ac
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Strictly speaking, we don't need the *bus*, only libdbus-1, but some
machines in our CI appear to be misconfigured somehow. I don't
understand how they can both have and not have this library in the same
run.
Pick-to: 6.5 6.6
Change-Id: I80612a7d275c41f1baf0fffd177a66a04951948c
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
We've known for a long time that this is producing worse code with GCC
because of how we implemented in Q_ASSUME_IMPL(). So bite the bullet and
actually deprecate the macro, replacing all extant Q_ASSUME() with
Q_ASSERT().
The replacement is in C++23. Backporting the support onto Q_ASSUME_IMPL
was previously rejected by reviewers.
[ChangeLog][Deprecation Notice] The Q_ASSUME() macro is deprecated. This
macro has different side-effects depending on the compiler used (GCC
compared to Clang and MSVC), and there are certain conditions under
which GCC is known to produce worse code than if the macro was absent.
To give a hint to the compiler for optimizations, use the C++23
[[assume]] attribute.
Change-Id: I80612a7d275c41f1baf0fffd177a3a4ad819fb2d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Call QDBusMetaTypeId::init() in the cosntructor. This ensures that
the custom metatype registry is not destroyed before the instance
of the connection manager.
Task-number: QTBUG-58732
Pick-to: 6.6
Change-Id: I8c7c4c23deab2c7e11c6389a8976666ccf6baf48
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Already there in the .pro.
Change-Id: I2f4312310b80ad3403f242ba387218e8ec86bcb4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Clarify that Qt will silently truncate oversized keys for
QSystemSemaphore and QSharedMemory. This can have implications for some
use-cases, for example if an absolute path file name is used as a key
name to synchronize access to files.
Change-Id: I74742d11fd72139ff69d033e611904dcf0e9e822
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This constructor matches way too many argument types (integral,
unscoped enums, FP types), so it's likely to cause mayhem, even if
left in as an explicit constructor.
We now have a named constructor for the same functionality, so just
drop the "unnamed" constructor.
"Unnamed" constructors are important when emplacement is more
efficient than construction + move, or when implicit conversion is
required. Neither is the case here: The named as well as the
"unnamed" constructors just copy ten bytes around, and the compiler
can optimize those extra copies away just fine.
Found in API review.
Pick-to: 6.6
Change-Id: I7faafd3ebf522fb2b0e450112fb95d643fece5ce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QSharedPointer is 'meh', see QTBUG-109570 and 18113e22e9.
This is just a textual replacement of
- QSharedPointer<(.+)>::create() → std::make_shared<\1>()
- QSharedPointer → std::shared_ptr
And it compiles and still passes. No non-standard APIs to fix up.
Task-number: QTBUG-109570
Change-Id: I827d4a9be0511780c3900bd53ffcbdcb6aacbc3b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
All of these fall into the trivial category: loops over (readily made)
const local containers. As such, they cannot possibly depend on the
safety copy that Q_FOREACH performs, so are safe to port as-is to
ranged for loops.
There may be more where these came from, but these were the ones that
stood out as immediately obvious when scanning the 100s of uses in
qtbase, so I preferred to directly fix them over white-listing their
files with QT_NO_FOREACH (which still may be necessary for some files,
as this patch may not port all uses in that file).
Pick-to: 6.6 6.5
Task-nubmber: QTBUG-115839
Change-Id: I7b7893bec8254f902660dac24167113aca855029
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The original code duplicated contained elements of a QStringList by
repeated appending it to itself, preventing the container from being
marked const.
Instead, keep a list of unique mime-types, and iterate over the list
eight times.
As a drive-by, port from QList to a C array ("never use a
dynamically-sized container for statically-sized data"), use u""_s
UDLs (since we're touching almost all lines of the function, anyway,
also in the unrelated mimeTypeForName() call).
This allows porting the Q_FOREACH loop (which anyway cannot deal with
C arrays) to a ranged for one (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I844ae38104bb2980ea194b85f9017a3e95791ea2
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
These are all trivial: all are over (already or newly-made) const
local variables.
As a drive-by, replace a QList legacy left-shift-based- with
initializer_list-construction.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I453e24272c4c4b7dce5b91a0bd04481d833c50bb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
These are all trivial: all are over (already or newly-made) const
local variables.
As a drive-by, replace a QList with a C array
("never use a dynamically-sized container for statically-sized data").
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I1b1e8f093abf75093900631e6fe3cbc9e3019d34
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
These are all trivial: all are over (already or newly-made) const
local variables.
We don't have a mechanism to mark a subtree as Q_FOREACH-free, and
adding QT_NO_FOREACH to each executable is overkill, so we just have
to hope that no new uses are being introduced until we can mark the
whole QtBase module as Q_FOREACH-free.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I13dc176756633674bab8c93a342ecdba6c5dd23e
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When the placeholder text is changed after having been displayed, it
doesn't get updated on the screen any more, unless the entire viewport
is updated, e.g. because of a document change or a focus event.
This patch simplifies QPlainTextEditPrivate::updatePlaceHolderVisibility()
to update the visibility if the text document is empty.
It replaces the member QPlainTextEditorPrivate::placeholderVisible
by the function isPlaceHolderTextVisible(). It returns true, if the
document is empty and a placeholder text exists, and otherwise false.
It adapts and corrects tst_QPlainTextEdit::placeHolderVisibility():
- usage of new member function instead of data member.
- do not expect an empty placeholder to be visible.
Fixes: QTBUG-115831
Pick-to: 6.6 6.5 6.2
Change-Id: Ic4427ce7f7f1b8cde89957b9de0b978bd34ba923
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Were added for 6.6, but turns out they were not quite ready, and also
live better together with the quadpath class in the curve renderer.
This reverts commit aaccd50224.
Pick-to: 6.6
Change-Id: I58399f8e280d5353cb9c3102e8a8e15dcfa4484a
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Under some configure options, gcc13 emits an intractable warning on
this line. This patch works around it.
Fixes: QTBUG-115809
Pick-to: 6.6 6.5 6.2
Change-Id: Ib63f2ad81ebdb1f609a7f42c25119c5ae29f08bb
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Child windows on Windows cannot have a frame, so checking only for
Qt::FramelessWindowHint is not sufficient. Add an additional check
to see if the window is a native child (has the WS_CHILD flag).
Pick-to: 6.6 6.5
Change-Id: Ib5cbec0f6157da687a5585e12a6c4c6935919538
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Presumably it passes elsewhere due to pch or unity builds
Pick-to: 6.6
Change-Id: I69b52751765b12d2d4dd701c2e022c9014d6c16f
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
QMenuPrivate::hideMenu() hides a menu and reposts events in case a new
action has become the active one. For that purpose, it waits 20ms and
60ms for visual effects to be rendered.
If the last action has been triggered, the menu's deleteLater slot has
been called before hideMenu(). In that case, it gets deleted while
events are processed during the waiting periods.
Subsequently, menu becomes stale.
This patch replaces the QMenu * argument with a QPointer. Early returns
are inserted after waiting. QSignalBlocker is replaced by manual signal
blocking, to prevent the signal blocker from recovering the state of a
stale object, when it goes out of scope.
An auto test is not added: The error scenario occurs, when a menu is
triggered by keyboard input, while a mouse event is sent to the main
window from outside the menu. Such a test scenario is complex to match
and exposed to flakiness.
Fixes: QTBUG-115597
Pick-to: 6.6 6.5 6.2
Change-Id: I4f937fe66fb1b5cf78ebee70fd0006712172cb12
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The current implementation is not thread safe - it is possible
to update and query the network information without any locking.
Protect the internals of the backend with a lock and move the
object to the main thread.
Task-number: QTBUG-115748
Change-Id: I9511fc3522ae82cffca42abc54eb79cb156397c4
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QAndroidPlatformInputContext::focusObjectStopComposing() sends an input
event for each character newly added by the Android virtual keyboard.
It then sends a second input event to notify that the cursor has
advanced to the position after the new character.
The implicit assumption is, that the receiver of the input event does
not change the text.
If e.g. QLineEdit::setText() is called in the QLineEdit::textEdited
slot, the text does change. If the change implies a cursor change,
QLineEdit notifies the platform input context about it.
However, by sending the second input event, QAndroidPlatformContent
returns the cursor back to the position after the last character added
by the virtual keyboard.
This patch joins the composed text and the cursor position into one
single input method event. A new cursor position, set by the receiver
of the input method event, is no longer overridden.
The patch adds test functionality to tst_QLineEdit::setText().
Fixes: QTBUG-115756
Pick-to: 6.6 6.5 6.2
Change-Id: I85ffac5d6bab93ccb144be0f5b8083258a270550
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Add more tests on WebAssembly platform for better tests coverage.
Change-Id: Iaaaa824ae6058a9ae5dba4c4038a7f687bfc17e0
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
It referenced QDeclarativeComponent, which has been gone for a very long
time. Also replace the foreach with a proper for loop.
Change-Id: I7f30ca10a235137dbdf34b7684e2c38610242b17
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
Take 2.
Re-land previously reverted commit, due to not handling resource names
that are not valid c++ identifiers. Now we sanitize the resource names
just like rcc does by replacing non-alphanumeric characters with
underscores.
Original commit message.
During the Qt 5 -> Qt 6 and qmake -> CMake porting time frame, it was
decided to keep resources in an object file (object library), rather
than putting them directly into a static library when doing a static
Qt build, so that the build system can take care of linking the
object file directly into the executable and thus not forcing
project developers to manually initialize resources with
the Q_INIT_RESOURCE() macro in project code.
This worked for most qmake and cmake projects, but it created
difficulties for other build systems, in the sense that these projects
would have to manually link to the resource object files, otherwise
they would get link time errors about undefined resource symbols,
assuming they kept the Q_INIT_RESOURCE() calls.
If the project code didn't contain Q_INIT_RESOURCE calls, the
situation would be even worse, the linker would not error out,
and the missing resources would only be discovered at runtime.
It's also an issue in CMake projects that try to link to the
library files directly instead of using the library target names,
which means the object files would not be automatically linked in.
Many projects try to do that because we don't yet offer a convenient
way to install libraries and reuse them in other projects (the SDK
case), so projects end up shipping only the libraries, without the
resource object files.
We can improve the situation by moving the resources back into their
associated static libraries, and only keeping a static initializer as
a separate object file / object library, which references the actual
resource initializer symbol, to ensure it does not get discarded
during linking.
This way, projects that link using targets get no behavior difference,
whereas projects linking to static libraries directly can still
successfully build as long as their sources have all the necessary
Q_INIT_RESOURCE calls.
To ensure the resource symbols do not get discarded, we use a few new
private macros. We declare the resource init symbols we want to keep as
extern symbols and then assign the symbol addresses to volatile
variables.
This prevents discarding the symbols with the compilers / linkers we
care about.
It comes at the cost of an additional static initializer per resource,
but we would get the same + a bigger performance hit if we just used
Q_INIT_RESOURCE twice (once in the object lib and once in project
code), which internally needs to traverse a linked list of all
resources to check if a resource was initialized or not.
For GHS / Integrity, we also need to use a GHS-specific pragma to keep
the symbols, which we currently use in qtdeclarative to ensure qml
plugin symbols are not discarded.
The same macros will be used in a qtdeclarative change to prevent
discarding of resources when linking to static qml plugins.
A cmake-based test case is added to verify that linking to static
libraries directly, without linking to the resource initializer
object libraries, works fine as long as the project code calls
Q_INIT_RESOURCE for the relevant resource.
This reverts commit bc88bb34ca.
Fixes: QTBUG-91448
Task-number: QTBUG-110243
Change-Id: Idce69db0cf79d3e32916750bfa61774ced977a7e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If '-G<generator type>' is passed to configure script we should respect
this argument but not override it by the autodetected generator type.
'-cmake-generator' option will still have higher priority, but if
generator is set using CMake argument it will not be auto-detected by
other build config specific options, like '-debug-and-release'.
Change-Id: I75b49e33fa717f90bbd74045948fccb9f5350e8d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Headers must be free of Q_FOREACH uses if we want to white-list only
those .cpp files that still use Q_FOREACH in order to enable
QT_NO_FOREACH by default.
In common.h, the situation is pretty clear: the loop bodies clearly
don't modify the container being iterated over.
In MyServer, the situation is not clear at all, and this author
doesn't have the time to investigate, so take a copy and iterate over
that (eactly what Q_FOREACH does), and leave a comment.
As a drive-by, fix missing {} around multi-line loop bodies.
Task-number: QTBUG-115839
Change-Id: I06311a641c83daeee25f45522c694ac355ee86b6
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
The density of Q_FOREACH uses is high here, too high for this author
to tackle in a short amount of time. But they're concentrated in just
a few TUs, so pick a different strategy:
Mark the whole plugin with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. Since the TUs are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too).
Task-number: QTBUG-115839
Change-Id: I42c26cb5d95add115e57cc484a0e1a93ed368ddd
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
The QSystemSemaphore::platformSafeKey was intended to truncate oversized
keys on Windows, but didn't. The fix is to make sure MAX_PATH is defined
when compiling on Windows.
Change-Id: I03f3bee901203d901bda05a841451c8a2d2f3924
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
