... and make it a hidden friend.
This avoids ODR violations when, because they can't use ours (private,
and not exported), users try to produce their own version of
qHash(Key).
[ChangeLog][QtGui][QPixmapCache] Made the qHash() overload for
QPixmapCache::Key public (was: private) API.
Pick-to: 6.6
Change-Id: I324ed001c0ae0a251ac2e1d04713013452ffff9c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Just de-inline the original function instead of merely moving its
implementation into an out-of-line function.
Amends 408fbd3f2d.
Pick-to: 6.6
Change-Id: I6860a10e0a7d876ce1837f196b1fb4165779540a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
... to hold the optional QApplication.
Saves a memory allocation, and is more readable.
Amends 408fbd3f2d.
Pick-to: 6.6
Change-Id: I390b9cfa367d01feb59bb5deadc5383c8e678749
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
... instead of %s and qPrintable()
Less operations, less code expansion.
Amends 408fbd3f2d.
Pick-to: 6.6
Change-Id: I5a3d2e79623bd32c348a2d655e3a2c8d98eca1e3
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This is not scalable. Instead of putting parts of post-1.0 vulkan_core.h
into this header, apply the appropriate ifdefs instead.
Pick-to: 6.6
Change-Id: I21a9d6f7c51169efa7b66705545bae192ed30c14
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Just in case someone includes the private headers outside of Qt.
Pick-to: 6.6
Change-Id: I79232d2bab7604c71c31226a67ec3ef40210d161
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Without this patch, the compiler will complain about can't find
"qshaderdescription.h" when using "qrhigles2_p.h" from outside of
Qt, which breaks user project compilation.
Pick-to: 6.6
Change-Id: I9e201d82890c92ddd2f6aad48eef0edc9a7c46ef
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The existing implementation as a member function QDALI::op<<(QDebug)
cannot possibly work, as the implicit `this` argument comes first in
this case, while for streaming operators, the QDebug object must come
first.
Rewrite as a hidden friend and apply QT_NO_DEBUG_STREAM protection as
a drive-by.
Amends faec937756.
Task-number: QTBUG-114542
Task-number: QTBUG-112491
Pick-to: 6.6 6.5
Change-Id: Ida400d335491896ec49f2c0f9601a8430eebcd4d
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
They're RAII/smart pointer-like classes. QUIP-0019 says such classes'
ctors should be marked [[nodiscard]].
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I830badfa56fbdfb5819866f67b84cd4fa93acbde
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QWidgetPrivate::focusObject() always returns nullptr. That has lead to
mismatches between QGuiApplication::focusObject() and
QApplication::focusWidget(), when a widget got focus by the window
system (e.g. mouse click).
This patch implements QWidgetPrivate::focusObject.
It returns the current widget, if it doesn't have a focus proxy.
If it has a focus proxy, it resolves the proxy chain and returns the
deepest focus proxy.
(Note: It does not return QWidget::focusWidget(), because the focus
widget might not yet have been set, when the method is called).
Fixes: QTBUG-92464
Fixes: QTBUG-108522
Pick-to: 6.6 6.5 6.2
Done-With: Liang Qi <liang.qi@qt.io>
Change-Id: Icf01e8ac4fc5f722fbf8e0ca5a562617ae9ae8f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
QSqlResult::boundValues is a const member function, but returned a non-
const reference to a QList<QVariant>. This is a bad and potentially
dangerous API, as callers can modify the list stored in QSqlResult.
Move that API into the removed_api translation unit, remove it from
Qt 6.6 on and replace it with two suitable overloads where the const
version returns a QVariantList by value, and the non-const overload
returns a mutable reference.
Driver implementations that used to call the const overload to get a
mutable reference are now calling the non-const overload instead
(those calls are all made in the non-const exec() or equivalent driver
implementations).
As a drive-by, replace "vector" with "list" in the documentation.
Pick-to: 6.6
Change-Id: I6e4fd8f5749b939cdb609bf5876735e9b30b2b5a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Code points is what you get when surrogate pairs have been joined
Pick-to: 6.6 6.5 6.2
Change-Id: I86c4131de5782ce1e6342217947a603ca16bb521
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the new argument to bundle the OpenSSL prebuilt libararies so that
ssl operations are actually tested at runtime.
Task-number: QTBUG-110025
Pick-to: 6.6 6.5
Change-Id: I0d73fed463a1724a9e0ee84ba603aa2ff1bc649b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The new argument would allow bundling the prebuilt OpenSSL libs
into the test apk so that SSL can actually run. It expects the CMake
argument OPENSSL_ROOT_DIR to be set ( we set that in Coin configs).
Task-number: QTBUG-110025
Pick-to: 6.6 6.5
Change-Id: I4c82796635ca89f5511255ae26182f41a504b026
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is in line with how QMetaType handles QMetaTypeInterface*. You can
retrieve a const pointer to it.
Pick-to: 6.6
Task-number: QTBUG-113690
Change-Id: Iaf3c10603dc6049a5553987c90006807867abc0d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Prior to 30276cec3d all the recognizers
were managed together, so we could safely condition teardown of them
all by checking for the presence of one of them.
Now that we selectively enable only some of the recognizers, we need
to have more granular teardown logic. For extra safety, we tear down
each one individually now, even if some of them are still managed
together.
Pick-to: 6.5 6.6
Fixes: QTBUG-114416
Change-Id: Ie99388cd8abb7543c17df5b6b5a88e86ff86df7e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
Our logic in the edit menu tap recognizer for determining whether the
tap should trigger the edit menu only looks at the bounds of the input
area, and as long as the tap is within these bounds we trigger the edit
menu.
This doesn't take into account that there might be controls laid on top
of the input area, for example a button, where we don't want to trigger
the gesture.
The only related logic we have is a heuristic that checks whether the
cursor ends up moving as a result of the initial press, in which case
we treat it as the edit area "accepting" the touch press.
The proper fix to this is to handle the gesture recognizer delegate
callback gestureRecognizer:shouldReceiveTouch:, and do hit testing
there, but we don't have any machinery for that in our IM protocol,
nor in QWSI.
As a workaround, we treat the gesture recognizer as having failed,
even when we do detect a tap that should open the menu, so that the
recognizer doesn't eat the touch event. We then open the menu manually
instead of relying on the gesture recognizer changing state. This
should be safe, as sending a touch/mouse event down to the input
area should normally be a noop.
The workaround does result in a slight visual wart when clicking
buttons that live inside input areas, as the edit menu temporarily
opens, but the menu is quickly hidden again as the focus object is
transferred to the button. Compared to the current situation, where
the button is visually pressed, but doesn't do anything, and we
bring up the edit menu fully, this is an improvement, even with
the wart.
Note that the original problem outlined in this changed is not an
issue in practice for Qt Widgets, as we synthesize mouse events
from touch events, and (wrongly) synthesize a mouse release in
response to the touch cancel triggered by the gesture recognizer,
so the button is still activated.
Fixes: QTBUG-113975
Pick-to: 6.5 6.6
Change-Id: I41e850f20d69ad8e3247949644a389e1c61c4dcf
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
ACE-encode the domain names, replace dashes with underscores,
prepend underscore to domain name parts that start with a digit.
Add a regression test into tst_qdbusinterface.
Fixes: QTBUG-71674
Change-Id: I92e0c6889163c0eccc4c833f2058d759631f562c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Or old and new load hints in mergeLoadHints() instead of just storing
new ones. Andjust QLibraryPrivate::setLoadHints() to handle objects
with no file name differently and just set load hints directly.
Mention that load hints are merged once the file name is set
in the documentation for QLibrary::setLoadHints().
Add a regression test into tst_qfactoryloader.
Update and extend tst_QPluginLoader::loadHints() to take into account
load hints merging.
Fixes: QTBUG-114480
Change-Id: I3b9afaec7acde1f5ff992d913f8d7217392c7e00
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code is commented out since 12 years ago.
Change-Id: I5cd7380f8f1e778ea62b510aeece1aced111d662
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's not a real leak in that the string data is being freed on program
exit (or, more recently, QPixmapCache::clear()), but it can lead to
lots of memory being bound for much longer than expected when users
put in new QString keys without attempting to retrive them again. It
can also lead to problems with QStringLiterals lingering around until
after their underlying data has been freed. A bug in the Fusion style,
generating new string keys for identical state, exposed this
misbehavior, and one way to fix the resulting issue for the user is to
make sure that QPixmapCache doesn't leak QString keys.
The Fusion style issue with generating non-repeating keys for use with
QPixmapCache should also be fixed, eventually, but this patch
relegates that to an optimization issue (the caching is effectively
non-existent), the resource exhaustion is gone now.
The issue exists because the QString keys are internally mapped to
QPixmapCache::Key's by way of a QHash<QString, Key> cacheKeys data
structure. When the QCache, indexed by Key, not QString, decides to
evict an entry, the Key is invalidated, but no-one was removing the
corresponding entry from cacheKeys. So make the existing releaseKey(),
used to invalidate copies of Keys referring to evicted pixmaps, do
that, now. So as not to have to scan the whole cacheKeys QHash for the
right Key, store the QString key, if any, inside the Key, so
releaseKey() can retrieve it and use it for O(1) erasure from
cacheKey.
This allows removing the previous work-around in clear()
(6ab0d25a09), greatly simplify
object(QString), and requires to rewrite all code that holds iterators
or references into cacheKeys over an insertion into or removal from
the QCache. Two (insert() and remove()) have already been done in
prequel commits, so only flushDetachedPixmaps() was left.
Fixes: QTBUG-112200
Pick-to: 6.6 6.5
Change-Id: Ic93b0ed388ae963267fe242b491c6c941d146b99
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Implement insert(QString, QPixmap) in terms of insert(QPixmap) to
avoid duplicating code and to separate concerns: insert(QString,
QPixmap) is now only dealing with the cacheKeys, insert(QPixmap) is
only concerned with the Key-based lookup.
Task-number: QTBUG-112200
Pick-to: 6.6 6.5 6.2
Change-Id: I30394da43a5e93b7bd41ef9ce9c7aea044523c30
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The previous code used `cacheKey` as the name of an iterator, which
made the code hard to understand.
Instead of renaming that to the more idiomatic `it`, use QHash::take()
to get an actual `cacheKey` back, and then delegate to
QPMCache::remove(QPixmapCache::Key) for the actual removal.
Pick-to: 6.6 6.5 6.2
Task-number: QTBUG-112200
Change-Id: I9311c19f12a05cad694702672f17ae19ba339b04
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's a RAII class, and RAII classes should have only [[nodiscard]]
constructors.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: Ia83fa003677a839734208b12bde2c6287c1b79a3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
They're RAII classes, and QUIP-0019 says RAII class' constructors
should be marked [[nodiscard]].
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I0080f5b6a3cea346c0860e00958a8c204849040e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We should not export non-polymorphic classes wholesale. Only export
the non-inline functions instead.
There are no implicitly-declared special member functions in this
class that could cause problems, so we don't need to delay until Qt 7.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I2e98782160cccb9c0f59a68e67ffd29fec42b728
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Amends 55fe46fd58. Before that change,
key release events were ignored as the QLineEdit::event reimplementation
continued to call QWidget::event, and as QLineEdit didn't override
keyReleaseEvent, the default implementation in QWidget got called to
ignore the event.
Restore that behavior by explicitly calling the QWidget implementation
after updating QLineEdit-specific states, and add a test case.
Fixes: QTBUG-114654
Pick-to: 6.5 6.6
Change-Id: Ic8aa35a1c915b446aece47aaf03ef5cf1884b936
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
A number of users have explored the behavior and complained about it.
Lets add a \note explaining this. The function in charge is
QThreadPool::stealAndRunRunnable(QRunnable *), which is a private
function, exclusively used by:
QFutureInterfaceBase::waitForResult()
QFutureInterfaceBase::waitForFinished()
also update the documentation to reflect these changes accordingly.
Fixes: QTBUG-112351
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I839858cb449063d8af9bef64d2f35a6816a419b0
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Previously, failure handlers did not propagate cancellation. This would
lead to crashes when a QPromise was cancelled without having generated
any result. Subsequent continuations would be invoked and try to access
the result (which was nonexistent) and then crash.
This patch propagates cancellation through failure handlers to prevent
subsequent continuations from being called in the first place.
Fixes: QTBUG-114606
Pick-to: 6.6
Pick-to: 6.5
Change-Id: I23b28a8e70a76e1ba6416be4440360c6dbaef2a3
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The export name is now ${TARGET_NAME}Entry. This can also be overridden
by using QT_WASM_EXPORT_NAME, both in CMake and qmake
Change-Id: I59c97ae6e22f0b2720716e9d7eff7b6b13d37ab5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The alternative would be to explicitly cast each list.size() to int. I
think using iterators is a cleaner solution.
Drive-by changes:
- Give a std::pair's members better names than first/second, by using a
structured binding
- Port to qsizetype
Pick-to: 6.6 6.5
Change-Id: Icff3126192f9813fba698d5722b209307011ca48
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It was always 0
Task-number: QTBUG-113679
Pick-to: 6.6
Change-Id: I090036296ad2df99b986400863b1e57a5d6101fb
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Since they don't contribute to the width of a string then we may
accidentally end up ignoring the potential left-bearing that the first
non-zero-width glyph has.
Task-number: QTBUG-113679
Pick-to: 6.6
Change-Id: I8e89a428acf5d0a3da0255c50778ccc773ff20e1
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
On WASM, the shortcut triggering the dialog in textedit example
seemingly lets the event invoke the default action. What really happens
is that the dialog's exec() does not return and WASM does not have a
chance to set preventDefault() on the keyboard event it receives. This
masks other problems with keyboards shortcuts.
Uses of exec() on message boxes were replaced, too. Closing operation
is now performed in two steps, first the event is ignored and maybeSave
is called to query for potential changes of the text document.
If there are no changes or the file is discarded, the close continues
with a second event, now accepted.
PrintDialog::exec(), QPrintPreviewDialog::exec(), QFileDialog::exec()
were also eliminated in favor of open().
Finally, indirect calls to exec() via QColorDialog::getColor were
removed.
Task-number: QTBUG-76587
Change-Id: Ia90fad46ec3f94244723512be3ec93b64df9d9ef
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
The lack of 0x adornment made hex confusing. `xinput list` shows device
IDs as decimal, and device IDs appear in decimal in some categorized
qt.qpa.input.devices log messages, so let's be consistent here too.
Also fixed one more that was inconsistent in that category:
"scroll event from unregistered device <x>"
Change-Id: I98a39b30b1bc030611d3cfe9dd5e95886faf48ff
Pick-to: 6.5 6.6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We want to pass the QPointingDevice* because we've already identified
it by its "system ID" (xinput device number). The other versions of
handleTabletEnterProximityEvent and handleTabletLeaveProximityEvent
try to identify the stylus by only its deviceType, pointerType and
unique ID, which can go wrong if there are multiple tablet devices and
the unique ID is not provided (as with N-trig and Wacom tablets being
used at the same time). Anyway this fixes a TODO comment from
6589f2ed0c
Leave a "deprecated" comment by the QWSI functions that should not
be used.
Pick-to: 6.6 6.5
Task-number: QTBUG-104878
Change-Id: Id9f19c60b54b7900b02d5f87b5d12f9a9189721d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a dock widget is hovered over a QDockWidgetGroupWindow, a gap item
is inserted at its potential docking position. Since only one item at a
time can be moved with the mouse, only one such gap item can exist.
QDockAreaLayoutInfo::insertGap() therefore contains an assertion, that
kicks in if a second gap item is inserted.
QDockWidgetGroupWindow::hover() checks if the dock widget is hovered
over a gap item. If that is the case, no additional gap item is
inserted. The check fails if a gap item exists in the group window, but
the dock widget is hovered over another part of that group window.
This can be the case if the group window already contains more than
one dock widget: By inserting the gap, the group window's size changes,
one of the existing dock widgets receives another hover event and a
second gap insertion is attempted.
This patch adds QDockAreaLayoutInfo::hasGapItem() to check if a gap
already exists. The method is queried in addition to prevent a second
gap insertion.
An autotest has not been added, because gap items appear and disappear
during hovering. The improved functionality can be tested manually with
the mainwindow example.
Fixes: QTBUG-112491
Fixes: QTBUG-114542
Pick-to: 6.6 6.5
Change-Id: I9ea64e729873a86eb98ea950fbb066817fc25a07
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QDockAreaLayout items can be widgets, gap or placeholder items.
They appear and disappear during hovering.
This adds a debug operator to make troubleshooting easier.
Task-number: QTBUG-114542
Task-number: QTBUG-112491
Pick-to: 6.6 6.5
Change-Id: I0fa5d3c96ab91838f28ad7cec3c049fd39f47576
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QObjectPrivate::getPropertyAdaptorSlotObject called
connectionsForSignal.
Calling this function is only safe after it has been ensured beforehand that the vector has size > signalIndex. As getPropertyAdaptorSlotObject
is not supposed to modify the vector, it does not resize the vector and it could consequently end up with an out-of-bounds read.
To avoid that issue, we instead first check if the vector can
potentially contain an entry for the signal. If not, we simply return
nullptr, and avoid the call to connectionsForSignal.
The issue and its fix can be verified by running the modified
tst_qproperty test with ASAN enabled. The test is modified in the
following way:
- We first create a signal connection to a dummy slot. Otherwise,
connections.loadRelaxed() would return a nullptr, and the problematic
code would never be reached.
- We add enough signals to ensure that the fooChanged signal will
actually be out of reach (which means >= 8 signals, as the initial
capacity of the vector is 8)
Running the test without ASAN will most likely not result in a failure,
as then the out-of-bounds read will simply read garbage, and the most
likely result is that the cast below will fail.
Pick-to: 6.6 6.5
Change-Id: I18a3c4f52769c2b6491a685abb84f6fcfb44e4d8
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
It is possible for an application to trigger the unexpected result of
NSModalResponseContinue from our call to NSAlert::runModal, by showing
and hiding a modal dialog first, and processing events explicitly. This
at best only flashes the native message box, at worst it triggers an
assert from our processResponse function evaluating that response value
as impossible (via Q_UNREACHABLE).
We should never call processResponse with NSModalResponseContinue,
but instead keep the modal loop running and the dialog visible.
So introduce a wrapper to NSAlert::runModal that keeps calling that
method until we get a result other than NSModalResponseContinue.
Writing an auto test for this failed; a simple test didn't reproduce the
assert; trying to place the opening of the native message box into a
lambda that would be called by the event loop (simulating the button
press from the bug report's reproducer) resulted in the native message
box never closing and the test blocking (and still not triggering the
assert).
Fixes: QTBUG-114546
Pick-to: 6.5 6.6
Change-Id: Iab25eff55c48b103287d1881ac355e6cdd190f7a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This property can take a either a WebAssembly.Module
or a promise to a module, and we don't have to specify
the exact type in the property name.
Pick-to: 6.6
Change-Id: Iebaf52178253afe8c93cf78bbe0853461bf48b67
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
This is required when using the preload functionality
from qtloader.
Pick-to: 6.6
Change-Id: Ib1bf8788b87834ba0ff80d563897040e093a16b9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Set `QT_COMMAND_LINE_PARSER_NO_GUI_MESSAGE_BOXES` before trying to run
qt tools for correctness. This is to suppress QCommandLinerParser from
showing a message box when console is not available.
Pick-to: 6.5.2 6.5 6.6
Task-number: QTBUG-114530
Change-Id: Ib3d264a799a5da1f620d2bebe55539bafc43da0f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an environment variable to be able to stop QCommandLinerParser
from showing GUI message boxes when console is not available.
Pick-to: 6.5.2 6.5 6.6
Task-number: QTBUG-114530
Change-Id: I52500a2177894bc0bf2d20f9723ce3e8fe87420f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The test checks whether correct windows get correct keyboard input,
having been activated with mouse clicks.
Also fixes the event propagation error found. Key events would propagate
to parent windows, which is something that should not happen with
window managers.
Change-Id: I18bae8c14cce5ccae151c2a00c84ffdba3b4587f
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
