This is a left-over from when setFamilies() and setFamily() were
setting two different properties, for compatibility reasons.
There is no longer a special step for the singular family, and the
sentence is also a bit obfuscated, so we just remove it.
Change-Id: Ia3c244d41f550a5062de8de63053770258dcacba
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
(cherry picked from commit 0ed324314bf151894be9bdd8272adbbc63c2b0ee)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
currentTextChanged is emitted when the current index changes
and the current text doesn't.
This can be the case, if
- old and new index have identical text values
- an item is removed below the current index
[ChangeLog][Widgets][QComboBox] emit currentTextChanged only,
if currentText changes.
Add a corresponding test in tst_QComboBox::currentText().
Fixes: QTBUG-113717
Change-Id: I847874f0792b29a2841e50bb82d06ad496fb02c3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 9195438a5fd88c676b0fc4abd429bcffa6f97e24)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
After 140ca89a3c2b8d78889d27217f977cd4de10041b commit, the path of the
QSettings default file location changed. That caused the problem with
updating the app (old settings file is not used anymore). That is why we
should still use old (.config) directory for QSettings file if the file
exists.
Fixes: QTBUG-109405
Fixes: QTBUG-109369
Change-Id: I8ce53e0a80e4c2d16802b27b000ab3fbed198628
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit beaaa0bf02fee696b03f2839bea8e0e6bc685a62)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
- Use modern string literals (use QStringLiteral instead of
QLatin1StringView for strings that go into the DOM API).
- Use mime types in the file dialog handling
- Streamline code
- Remove mentions of SAX
- Use per class includes
- Do not use QObject::tr()
- Use the configure system instead of QT_NO... defines
- Fix some doc text typos
Complements 3dd3268ded4dd74c64d7ec726fd534375ab9f018.
Task-number: QTBUG-111974
Change-Id: If0dc7b61e729d0a71f37743efc9b82e285d3f451
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit 3a553507a134bee1562d34ebbf786a053d36fc05)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Clang's macro deprecation pragma was introduced in Clang 14,
shipped with Xcode 14.0.
We can't version check Q_CC_CLANG here, as qcompilerdetection.h
hasn't been included at this point. Nor would it have helped much,
as we would have had to do so for each individual define we wanted
to deprecate, since mentioning an undefined define in the deprecation
pragma is an error. And we can't wrap the pragma in another macro
that conditionally expands to _Pragma either, as the input argument
is a define that needs to be passed on as is, without expanding it.
So the simplest way to support < Xcode 14 is just to silence
the unknown pragma warning.
Change-Id: Icf95042e6186deb212cd1793eb12ba32206ce34b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 3c12c3d58c5e27a5792eb85de994539c17ef2c38)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The HDR info is independent of the current format anyways.
Removing the format check allows code to use hdrInfo() as
a signal for whether to set a HDR format, instead of having
to set the format, then query hdrInfo(), and then setting
SDR again if needed.
Change-Id: I99b57335003d06af227f2a7078560c2a483b049b
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 5ea0256b07495977a1f2740f6b2d99984cf927dc)
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The code is mostly an implementation of a model based on QStorageInfo,
shown in an otherwise uninteresting tree view.
Change-Id: Id6ce70d71ddc9bcd6e82a9ee12f5e1af159eac7a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit a89f575be3a410a06165dc19961b1a260a67464d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The example seems incomplete, is undocumented (and unused in shippets,
in spite of tags being present), and generally full of comments that
give the impression that this is for manual testing rather than showing
best practices.
Change-Id: Ie615420e493cc6bb461c5d9ff8d4ae82bb3591db
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit b908c5cf28923a3ae2d9262361a9810bc57cc9c7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The relevant bits are a two-line snippet.
Change-Id: Id1731e5bc6585b1d1fd684817b39d19ad0a8a9cc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit ce13dc8c2f73408ce2897f4bd044560955e38145)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
`TYPE` argument is not a thing, and if it is there, QT_BUILDING_QT is
set to `TRUE;CACHE;TYPE;STRING;When this is present and set to true, it
signals that we are building Qt from source.` instead of `TRUE`.
Change-Id: I24784e9aead4929d408d06bce72d3f33ee21eb63
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 5d12d9846a9436b4ef4e1f8ac42d081d60568ecf)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The replace() implementation overwrites the passed Key key with a new
version, const_cast'ing away the const from the key passed by
reference-to-const. This is UB if the Key was originally declared
const.
Deprecate the function.
Also inline the const_cast, so compilers can readily detect the UB
even if users don't enable deprecation warnings. Due to the severity
of the issue (UB), immediate deprecation is warranted. There appear to
be no in-tree user of the API outside of tst_qpixmapcache.cpp.
[ChangeLog][Deprecation Notice][QtGui][QPixmapCache] The `replace(key,
pixmap)` function has been deprecated, because passing a `const Key`
to it results in undefined behavior. Use `remove(key, pixmap)`
followed by `key = insert(pixmap)` instead.
Change-Id: Ic5060ce3271f2a1b6dc561da8716b452a2355d4c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 78cdd9a64dc0cd666e5c8daafa7477c29641420d)
Between the find() == 0 obfuscation (since fixed) and this unchecked
replace(), it took me way too much time to figure out what was going
on: the key passed has been invalidated by the setCacheLimit(0).
Now that we QVERIFY that the replace() _fails_, it's much easier to
backtrack and figure out why it does so and why, consequently, the
following find() is also expected to fail.
As a drive-by, reorder two lines so the grouping becomes clearer
(blocks now both headed by setCacheLimit()).
Change-Id: I434b65fc13c3fed6512036efeb98d738eeb2a13d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 0e96dd3464bc2e03d66ebb574a7a5352942ffdb2)
None of the existing tests failed when I started to return a valid key
from a failed insert(QPixmap), so add a test that would fail.
Change-Id: I74f23d2ec4c04151f8f1266c0c503713d4642f3a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit e409d771d922b9772a0ecb4da575c6fd6f95676f)
It wasn't obvious to me, at least, and I only found out about it when
I failed to construct a test failure based on this.
Change-Id: I339132d7bb2cb8a76f0f1feec37891d6131c4d7b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 588ca25e4a31642bf8d18cd1948c50fa514ac0a7)
QMenu's causedStack maintains a list of menus on the way to the menu,
and might contain nullptr if one of the entries was a tear-off menu
that got closed (and thus destroyed, due to DeleteOnClose).
If the entry we get from the stack is nullptr, fall back to the passed-
in parent widget pointer, and test for nullptr before accessing.
Add a test case that crashes without the fix.
Fixes: QTBUG-112217
Change-Id: I958182db47c3cc8733e1780f7efef43881ffae11
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit f0049873d2ce0742a2df7ce265db70ca8baa8442)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We observe failures in CI on QNX because the measured timeout is ~995ms
rather than the expected 1000ms. Start the timer before the thread
starts to guarantee that at least as much time elapses as the thread
waits before writing the second byte to the pipe.
Otherwise, the thread might be sleeping already when the timer starts,
and then we can't rely on any measurements.
Change-Id: I6072569a987f5e952b0953e0e394a223f891fd25
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
(cherry picked from commit 30e5ff3ff223d665fbed3baf2d08ad3fcf2b8455)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The conan experiment has ended, and the file is only bitrotting
nowadays.
Change-Id: I8408265f7db7e52803b1f532d08a11387ea978cb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 9decda9063790ad1782d4a623a6a2857e857ebf9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
And add some additional parenthesis for extra safety.
Amends f7c8ff511c30dc4310a72b3da4b4a345efe1fba0.
Change-Id: I4ca8b70f6adb876a10f82685ba9800021218d418
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
(cherry picked from commit e84c0df50f51c61aa49b47823582b0f8de406e3d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
These are already defined in AvailabilityVersions.h in the SDK,
and we expect people to build Qt against the latest SDK available.
The corner case of requiring defines for upcoming/beta SDKs can
easily be handled by using the version number directly, which is
the recommended practice anyways.
Change-Id: Ica296118ee17608b8c43f9338c3083189083474c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 569c78162a739afcb2605dd253fde60a75014c86)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Availability.h from the platform SDK should take care of this these
days.
Change-Id: I23dd821682db66a1f22b1240d485f4a9cc877cd8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 329db8b64f17c8ef013c586cea1f1c5b49c4a4b7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If we have only one item, we're not using beginDraggingSessionWithItems
which requires us to manage our own drag loop, and instead use good old
dragImage, which takes care of the drag loop on our behalf.
In both cases we end up in draggingSession:endedAtPoint, so we need
to explicitly check for the existence of a manually managed drag session.
Amends 8a359343621fa83941946cb4e661b54ca7a1c4cc.
Fixes: QTBUG-114236
Change-Id: Ifa9110945e191c4ffebe099e3e4edf9c571ab376
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit f1011bd2ed3747880e08791fddbb63f73b0faffe)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In that case, just like when os_log mirrors to stderr by itself, we
want to disable Qt's fallback stderr handler.
Change-Id: Ia373b19788edbce616d4f0d3d9f0b217ddc1e5c0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 366923b597a56d9a5fa4ac04876ac65c1e0a4d59)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The UIAccessibilityScreenChangedNotification will result in iOS resetting
its state, focusing the first a11y element on the screen. We shouldn't
tie clearing the a11y cache to this notification, as those are two
separate actions.
In the case of adding or removing individual elements, we still likely
need to clear the cache, but can inform the system of the more granular
UIAccessibilityLayoutChangedNotification to have it re-read the a11y
tree.
We still handle additions and removal of a11y elements with Window
or Dialog roles as UIAccessibilityScreenChangedNotification, as these
likely involve major UI changes.
The implicit UIAccessibilityScreenChangedNotification on QIOSWindow
destruction has been removed, as it's assumed iOS will automatically
refresh its a11y tree when a UIWindow is destroyed, and in any case
it's up to the individual clients of QAccessible to send the relevant
QAccessibleEvent to inform about the situation.
Fixes: QTBUG-100094
Change-Id: If7d5cb961743e5ca97d45553b05ae5e92f82d275
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit b006d6d9dea11ac788a54ee3ffd13a9463003a32)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
These are no longer in use in Qt.
Change-Id: Id07bc0e09a414754493562d3a48df55cc28c5049
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit af47a197a59675149db208088b4fe072215901dd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Knowing the maximum potential component value can be useful
to potentially (sic) opt out of an HDR code path if the maximum
color component value will be too low to make the additional
processing overhead worth it.
Change-Id: Ib1e1b7a745b236e1d137a1e7daf1248f1572e184
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 183629e3ef9286332fdefa15dbce1b1495ef079d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Although QRhiSwapChainHdrInfo uses 'max' for this value, it's used
by Qt Multimedia's QVideoWindowPrivate::render() as the current
maximum, so we need to reflect UIScreen's currentEDRHeadroom
rather than potentialEDRHeadroom (the absolute max), the same
way we reflect maximumExtendedDynamicRangeColorComponentValue
and not maximumPotentialExtendedDynamicRangeColorComponentValue
from NSScreen.
As we don't support HDRExtendedSrgbLinear on < iOS 16 there
is no point in providing a heuristic fallback based on the
iPhone 12 spec.
Change-Id: If071bb64f269ce16886206df05eb9f27d260bf15
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 74319d05b1e8e2b5dcf226ef11bc66776460fa3f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The function was part of the Cocoa style for checking the metal
look (not Metal the graphics API), but has long been removed.
Change-Id: I366b952db4ae82b8ecc442f1ce61e7f53cacfe80
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 716df4965e75ff9e87278ea6753a4a311ce2c3bd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use new api calls for calculating pixel size and physical size
of multi-display setups after some existing apis have been deprecated
in Android API 30 and 31. Also, do the physical size calculation outside
of the supported modes loop.
As for the physical size, this patch still uses xdpi/ydpi for the
calculation instead of densityDpi as suggested in [1] because from
testing few scenarios, the results returned from xdpi/ydpi are more
consistent with physical device specs.
[1] https://issuetracker.google.com/issues/194120500
Task-number: QTBUG-112742
Change-Id: I0c8ef5185c8b6463830b528374954c324a32d657
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
(cherry picked from commit c0e0b56055e2ed0155d4e2402319dd8f8f134e10)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This amends commit f9c87cfd44bcf4b90cb45354252ef19f647b0469 to reset the
signal block mask too, not just the signal handlers. For this, SIGPIPE
is not treated specially.
Change-Id: Ib5ce7a497e034ebabb2cfffd17627289614bf315
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 062b2ac71bac1e0449eff7f8f02cb0020ad39991)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
I've investigated the functions we call in the child side of a vfork()
for implementations that do more than simply place the system
call. Where wrappers exist, they are usually related to handling of Unix
signals or PThread cancellation. The implementations investigated are:
- Bionic (Android)
- FreeBSD
- glibc (Linux)
- MUSL (Linux)
- NetBSD
- OpenBSD
Relating to thread cancellation, NetBSD implements it with an internal
API that does not include Unix signals and Bionic doesn't implement
thread cancellation at all. Their wrapper functions are harmless.
The rest do use Unix signals to implement thread cancellations (called
SIGCANCEL everywhere except OpenBSD, where it's SIGTHR). Therefore, they
all block the application attempts to mask this signal or change its
handler (if they're not buggy). FreeBSD's and MUSL's do some locking in
their implementations[1][2] we really want to bypass, therefore we must
bypass their sigaction() wrappers.
The investigation also showed that the glibc[3] and NetBSD[4] abort()
implementations to be slightly unsafe, but we don't use them
ourselves. We're also adding QProcess::failChildProcessModifier() so
users won't have to resort to abort().
[1] https://github.com/bminor/musl/blob/master/src/signal/sigaction.c
[2] https://github.com/freebsd/freebsd-src/blob/main/lib/libthr/thread/thr_sig.c
[3] https://codebrowser.dev/glibc/glibc/stdlib/abort.c.html
[4] https://github.com/NetBSD/src/blob/trunk/lib/libc/stdlib/abort.c
Task-number: QTBUG-113822
Change-Id: I9201d9ecf52f4146bb04fffd17651123800e15a4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit e71c226d6f188abd811b28d3cb7529343f52d61f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Pipes are unnamed FIFOs, so they're basically the same.
The difference here is that open() blocks on opening a FIFO until both
ends of the FIFO are opened. This helps us in synchronizing the two
threads and thus ensuring that that the read() system call deep inside
QFile does, indeed, block.
We see this with strace -T on Linux:
[pid 662956] openat(AT_FDCWD, "/run/user/1000/tst_qfile_fifo.2575572361", O_RDONLY|O_CLOEXEC <unfinished ...>
... aux starts up ...
[pid 662957] prctl(PR_SET_NAME, "QThread") = 0 <0.000004>
[pid 662957] openat(AT_FDCWD, "/run/user/1000/tst_qfile_fifo.2575572361", O_WRONLY|O_CLOEXEC <unfinished ...>
[pid 662956] <... openat resumed>) = 4 <0.000133>
[pid 662957] <... openat resumed>) = 6 <0.000011>
[pid 662957] clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=500000000}, <unfinished ...>
[pid 662956] read(4, <unfinished ...>
[pid 662957] <... clock_nanosleep resumed>NULL) = 0 <0.500183>
[pid 662957] write(6, "\2", 1) = 1 <0.000033>
[pid 662956] <... read resumed>"\2", 1) = 1 <0.500311>
Change-Id: I63b988479db546dabffcfffd1766d7a48819b149
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 01872d06d9a09c83f28b3ecebcb06f0ed81c5622)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When using move-only types, continuations args are set using takeResult
function, which has the side effect of invalidating the QFutureInterface
associated with the promise/futures by:
1. setting isValid to false
2. setting the state to NoState
And when the promise is destroyed, it tries to run the continuations if
`finished()` is not called, which is done by checking the Finished bit
in the state. But since the continuation has been run before, and the
state has been set to NoState it tries to run the continuation again
causing a segfault. Multiple solutions come in mind:
1. don't run the continuation if the state is NoState, but this would
break the case when an empty promise is destroyed
2. check inside the continuation if it has been run before, and if so
don't run it again, but this seems hacky since we don't want the
continuation to be run twice, and it should break if it did.
3. when invalidating the promise leave the state as is, and change
isValid only to false, which changes the current behavior, but is
still compatible with the documentation which states only that
isValid will return false if takeResult is called
I chose option 3
I also extended some tests to test for move only types, and added a test
that continuations run when a promise is finished. This simple case
would segfault before with move only types.
Fixes: QTBUG-112513
Change-Id: Ie225ac4fdf618e4edfb0efd663d6c7fd6b916dbd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 1f22fc995a36193cd67e8190858bb33614d149f4)
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If a foreground style has been defined in the style sheet,
QStyleSheetStyle populates its brushes for the color roles ButtonText,
WindowText, Text, and the widget's foregroundRole with the foreground
brush. PlaceholderText is set to the same brush with a modified color.
That sets their resolve bits in QStyleSheeetStyle's palette and
prevents these color roles from being inherited by the widget's
palette - in contrast to all other brushes.
This patch makes the brushes mentioned default to the widget's palette
if they are set there. It adds a test in tst_QStyleSheetStyle.
Fixes: QTBUG-93009
Change-Id: Ie3df9dbd17b96fa72beee90792fc7eca1933cdbe
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit c4635c0d5822d0e95ceca867fffb9ba86a2b7bfe)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This no longer is range-length preserving now, so adapt the
documentation.
For the non-contiguous iterator case, it's actually ok to always
resize(0) and then append(), because, unlike for QList and QVLA, the
resize(0) doesn't actually iterate the container to destroy
elements. It just sets some members and conveniently detach()es for
us.
The char8_t case is even more complicated, since we can, atm, not
include qstringconverter.h into qstring.h, yet qstringconverter is
required for stateful UTF-8 decoding in the input_iterator case. So
that's postponed to yet another patch, and maybe won't make it into
6.6. But I feel it's important to have at least one
non-length-preserving version of assign(it, it) in before release lest
users come to rely on this documented (and de-facto) feature of the
the step-2 assign().
Fixes: QTBUG-106198
Change-Id: Id458776e91b16fb2c80196e339cb817adee5d6d9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 05e388013098887eb66090b8f145ef92d60657db)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This is just confusing. QPixmapCache::find() already returns bool,
comparing it to a literal zero just makes it hard to read.
Change-Id: I43c000890377cca2111daa48799f10cc99aad8cf
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 6032845ca2fc69fb67971ea9f7e06588ffcbe9f3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Android's toolchain file, ie., android-legacy.toolchain.cmake assumes
that the default build is a Debug build, and it adds the `-g` flag to
CMAKE_<LANG>_FLAGS, as a result, our release Android build always
contains debug symbols. In this patch, I basically move the `-g` flag
from CMAKE_<LANG>_FLAGS to CMAKE_<LANG>_FLAGS_DEBUG, and
CMAKE_<LANG>_FLAGS_RELWITHDEBINFO.
Fixes: QTBUG-111901
Change-Id: I31eadb07d9172c923e8beaf0ac6c6e34fe1ebefb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 9d8a04cd1fd0a0c4ec891a9497512e4bbbaead9d)
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The method has been named expandingDirections() since the very
initial git commit for Qt 4.8 ... So high time to fix the
documentation.
Change-Id: If5d7189ebbe439bd0b0e95d51e77c08ee52c3471
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
(cherry picked from commit ef7e65e19a0ddf74a0cd72e59a83b9543426322b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
\c prevents qdoc from linking to the relevant function documentation.
Change-Id: Ieaa38b1feba816e911b17445a9436f64c234522a
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit 53fa325f4c4ae5721a4858eeec33ef79d19d1acf)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
I think this needs to be more prominent, as I noticed during the testing
that it could cause issues if it gets lost in between the config
messages, as we knew of course.
Task-number: QTBUG-113463
Change-Id: I2ece498a8d3604362a49cc10499b92b0d2764fb9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 9a5de496f1ff37b345010dd70304b2408f273322)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The screen's DPI need to be accounted for when calculating
the size in mm from pixels. This was missing after multi-displays
support was added for Android.
Amends fbf586db2c587e7ba83cf1bfe8e5b912310d6bdb.
Fixes: QTBUG-112742
Change-Id: I31814faa8de68e5193757d52e264b8ed90ae56b6
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
(cherry picked from commit 436923a76c4c60ad7271a66821768b06573310ce)
QString uses UTF-16 encoding and thus "unicode characters with
code values above 65535 are stored using surrogate pairs,
i.e., two consecutive QChars.". [1]
When the character inside of text is retrieved using the
GetCharacterAtOffset method of the AT-SPI Text interface,
use QStringIterator to retrieve the character's actual
codepoint instead of returning an invalid/incorrect one.
[1] https://doc.qt.io/qt-6/qstring.html
Fixes: QTBUG-113438
Change-Id: I07108481716329fd23a92c88892eaedd3f9defc6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit c7b925757f9b55924b788a2f08d777baa0e63250)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
...to only return true for HDR formats that are sensible for
Direct 3D. There are currently no other formats, but new ones
may get added in the future.
Change-Id: I4fc6d605da8f6bf2644a4e5c355ab8f1c62ad68d
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit 8a1915e04e2969a358aa5004bbd511cd92ce7372)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Although the header is available, and the compiler reports that the
standard library supports memory_resource, the feature is only
available on macOS 14 and iOS 17, as reported by
https://developer.apple.com/xcode/cpp/
As long as our deployment target is lower we can't unconditionally
use this feature. It's not clear whether the expectation is that
consumers of the standard library on these platforms will have to
runtime check their uses of these APIs.
Task-number: QTBUG-114316
Change-Id: I50c1425334b9b9842b253442e2b3aade637783ea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit f7c8ff511c30dc4310a72b3da4b4a345efe1fba0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
