It's a RAII class, and RAII classes should be marked [[nodiscard]] at
the class as well as the ctor level.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: Ie88023ba7c57dad7c2116c1c19a80b908b3a9f4d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Having the generic qt_itemFired: as action would result in the whole
submenu tree closing if an item with a sub-menu was clicked on. This
is not how native applications behave. They respond by immediately
opening the submenu, or do nothing if the menu is already open.
By using submenuAction: as the selector we achieve the same behavior.
A complication here is that for some reason we defer associating the
submenu NSMenu to an NSMenuItem until QCocoaMenu::setAttachedItem(),
instead of doing it in QCocoaMenuItem::setMenu(), or even as part of
QCocoaMenuItem::sync().
As a result, AppKit's NSMenuValidation logic will conclude that the
item does neither have a submenu, nor a valid target/selector combo
to be validated, and will explicitly disable the item. This can be
debugged by passing -NSTrackMenuValidation YES to the application.
To work around this we explicitly enable the item once we have set
a valid submenu for the item.
Pick-to: 6.5 6.6
Fixes: QTBUG-114199
Change-Id: I7178e7687066b3fe082454c512ec9c7eab3bded4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Declaring it as an explicit dependency should hopefully make
the compilers order the object-files to be linked in the
correct order.
Task-number: QTBUG-114243
Pick-to: 6.6 6.5
Change-Id: I723fee468e58786f66d1bba50bc4086beb50adb1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The idea is to store a concatenable in a QStringBuilder object by value
or by reference, depending on how it was originally passed into the
concatenation operator. So if it was passed by r-value, we treat it as
a temporary object and hold it by value (and use move-semantic if
available), otherwise we hold it by reference (as before).
To achieve this we first change concatenation operators '%' and '+'
to take their arguments by universal reference. Next we instantiate
QStringBuilder object with deduced types of the arguments, which will
be a "value type" or a "reference type" according to "universal
reference deduction rules".
Further we use perfect forwarding to pass arguments to QStringBuilder's
constructor. Thus arguments, initially passed by r-value reference
and which are move-constructible, will be "moved" to corresponding
QStringBuilder member variables.
So, to summarize:
1. Arguments passed by l-value reference - stored in QStringBuilder
object by reference (as before).
2. Temporary objects passed by r-value reference - stored in
QStringBuilder object by value. If a type is move-constructible
(QSting, QByteArray, etc), the object will be "moved" accordingly.
Special thanks to Giuseppe D'Angelo for the tests.
Fixes: QTBUG-99291
Fixes: QTBUG-87603
Fixes: QTBUG-47066
Task-number: QTBUG-74873
Task-number: QTBUG-103090
Task-number: QTBUG-104354
Change-Id: I64f417be0de0815ec5ae7e35a1cc6cef6d887933
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Vladimir Belyavsky <belyavskyv@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
In case the current GTK3 theme has no monospace font defined, a
monospace font requested by a Qt application can trigger a GTK warning
"Theme parsing error: <data>:1:0: Expected a valid selector".
The warning is triggered by Qt requesting "{font-family: monospace;}".
In this case:
=> ensure fallback to GTK standard monospace font
=> request "* {font-family: monospace;}" to avoid the warning
Task-number: QTBUG-112896
Pick-to: 6.6 6.5
Change-Id: I24a8da62908af9b153245f53026af60e63a600d7
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
As Eddy pointed out in review, the existing overload API docs says using
this method is discouraged; but adding a QDeadlineTimer overload is more
about preventing overflow, as it can handle qint64 or
chrono::milliseconds.
So it's either add this new overload or change the existing one to take
a qint64.
[ChangeLog][QtCore][QCoreApplication] Added processEvents() overload
that takes a QDeadlineTimer.
Task-number: QTBUG-110059
Change-Id: I02f938ee8243c09e493bd88ed496b862d87910f7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
It's a RAII class, and RAII classes should be marked [[nodiscard]] at
the class as well as the ctor level.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I77260dc00d51d62ed1064e13f566d04e88d28ef9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It's a RAII class, and RAII classes should be marked [[nodiscard]] at
the class as well as the ctor level.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: Ie877e261cfe602410d9d9bb3acc658d0bb7c4e72
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If flags use CMake scopes that propagate them to user libraries, it may
lead to an issue, if user projects are built using different compiler.
We need to guard these flags to make sure that they only will apply to
respective compilers.
Pick-to: 6.5 6.6
Change-Id: I0fd5847447bd8373e8e07f64dae11f27f48c915d
Reviewed-by: Alexandru Croitor (OOO) <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
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.
Pick-to: 6.2 6.5 6.6
Change-Id: Ia3c244d41f550a5062de8de63053770258dcacba
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
After 140ca89a3c 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.
Pick-to: 6.2 6.5 6.6
Fixes: QTBUG-109405
Fixes: QTBUG-109369
Change-Id: I8ce53e0a80e4c2d16802b27b000ab3fbed198628
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Fixes GCC 11 C++17 unity-build (didn't investigate which one is the
problem) error:
qsemaphore.cpp:275:7: error: ‘QSemaphorePrivate’ has a base ‘{anonymous}::QtSemaphorePrivate::Layout1’ whose type uses the anonymous namespace [-Werror=subobject-linkage]
275 | class QSemaphorePrivate : public QtSemaphorePrivate::Members
| ^~~~~~~~~~~~~~~~~
Amends fbc491230f.
Change-Id: I3b95a35822ec62aabd4c310b02bf58679bb9651f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
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
Pick-to: 6.6
Change-Id: I847874f0792b29a2841e50bb82d06ad496fb02c3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
- 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 3dd3268ded.
Pick-to: 6.6 6.5
Task-number: QTBUG-111974
Change-Id: If0dc7b61e729d0a71f37743efc9b82e285d3f451
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
- Use mime types in the file dialog handling
- Use per class includes
- Use the configure system instead of QT_NO... defines
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: Iea915604e89d3005270f0eb83eca882855589a44
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Regression after 585150e3d9.
Pick-to: 6.5 6.6
Change-Id: Ie728904736dd41fb8dfa6ecc9f843beea95b4604
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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.
Pick-to: 6.6
Change-Id: Icf95042e6186deb212cd1793eb12ba32206ce34b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is a chance that an unused variable warning will be treated as an
error, and in that case, this check will fail, and as a result FindEGL
will fail.
Pick-to: 6.2 6.5 6.6
Fixes: QTBUG-114431
Change-Id: Iaac49589144dbe4172ec58c6705a9f899c25f01f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
They existed because INTEGRITY hadn't yet been updated to the C++11
Standard Library, with a minor for broken MinGW cross-compilation builds
that forgot to enable gthreads support in libstdc++. The former appears
to have been since fixed and the latter is a massive toolchain
configuration mistake.
Change-Id: I63b988479db546dabffcfffd1766b55132371f9b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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.
Pick-to: 6.5 6.6
Change-Id: Ie615420e493cc6bb461c5d9ff8d4ae82bb3591db
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The code is mostly an implementation of a model based on QStorageInfo,
shown in an otherwise uninteresting tree view.
Pick-to: 6.5 6.6
Change-Id: Id6ce70d71ddc9bcd6e82a9ee12f5e1af159eac7a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The relevant bits are a two-line snippet.
Pick-to: 6.6 6.5
Change-Id: Id1731e5bc6585b1d1fd684817b39d19ad0a8a9cc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Detect if JSPI is available and suspend the execution of the program
if so, instead of using 'bare' asyncify.
For now:
1) This works only with emscripten 3.1.36 with mboc-qt patches from
emscripten repo
2) Apps have to specify the following linker options:
-sDYNCALLS=1
-sASYNCIFY=2
-sASYNCIFY_EXPORTS=dynCall_*
Fixes: QTBUG-113570
Change-Id: Ide7c51e36990df7e20c6c9b5a218366cb0db100e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Create the fixed string once and reuse it. Also give a name to the
escape code that's its repeated character.
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: I3d6416070f1d5490ec137e251daff0e1637fb788
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Put readBookmark() first of the constituent parts, as it's the most
intelligible (albeit currently undocumented) and gives some clue to
the purpose of readTitle(), which is next.
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: I91d3d6bf8adc3f3001c90274bb62a9da6bf05362
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
If the length of the quaternion was slightly larger than 1,
the resulting quaternion would be invalid, causing
getAxisAndAngle() to fail.
Fixes: QTBUG-114313
Pick-to: 6.5 6.6
Change-Id: I8f0616e74590dd6cfee0ce913d214c8e280c4df4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Don't show a blank frame on app startup.
The wasm update request system supports two types of update
requests: Expose and UpdateRequest. It can happen that both
types of request are made for a single window, in which case
the current code prefers UpdateRequest, since those must be
delivered in order to keep QWindow in a consistent state.
However, if the window is visible but not yet exposed then
delivering the update request will not make the window paint
anything, and we end up with a blank frame.
Ideally this should be handled elsewhere and QWindow::requestUpdate()
should not be called for non-exposed windows, but in the
case does happen then sending an expose here allows us to
recover.
Pick-to: 6.5 6.6
Change-Id: Ib53050c33ad1769ea9b9ad678896af15f87a7ecb
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
IFW requires static build of Qt which does not build tests on all
configurations. This allows building modules without them building tests. Previously IFW used 5.15 repos, those build tests in test workitem, not running into the issue.
This is only relevant if the tested repo i.e IFW implements it's own
test instructions.
Pick-to: 6.6 6.5 6.2
Change-Id: I1e03f3b577d7be314f92ed3989e5f6daf2a46da1
Reviewed-by: Toni Saario <toni.saario@qt.io>
If we wish to introduce a new color dialog option, then we might as well
use it in our example.
Change-Id: I7771d9d50e2ab0489fbeece8dea38a0b72b9b21e
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
These APIs started out as private APIs in qnumeric_p.h, but have since
been made pseudo-public in qnumeric.h. The qnumeric_p.h versions just
forward to the qnumeric.h ones, so just use the latter.
This is in preparation of removing the {add,sub,mul}_overflow
versions, which, despite being defined in the unnamed namespace, don't
sport the q prefix, so potentially clash with global symbols.
The change is a simple textual search and replace, manually excluding
qnumeric_p.h.
Picking to 6.5 to avoid cherry-pick conflicts going forward.
Pick-to: 6.6 6.5
Change-Id: Ic0f7c92f7c47923317109e8a9dc06fa66bdff2c2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If we have a rvalue reference to an unshared QVariant, we can avoid
potentially expensive copies, and use move semantics instead.
[ChangeLog][QtCore][QVariant] Added rvalue QVariant overloads of qvariant_cast<T>() and QVariant::value<T>().
[ChangeLog][Potentially Source-Incompatible Changes][QVariant] It is no
longer possible to take the address of a specialization of
qvariant_cast; consider using a lambda function instead.
Change-Id: Ifc74991eadcc31387b755c45484224a3200bb0ba
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Deduplicate it in the process by moving to qstringalgorithms.h.
In non-constexpr contexts, both GCC and Clang were giving up in
pre-calculating the length if the UTF-16 string literal was too big. For
the old code, that was 14 and 16 characters respectively. That number
can be raised by adding some Q_ALWAYS_INLINE and (for GCC's case),
replacing std::char_traits::find() with std::find(). If that limit is
exceeded, we call the newly introduced qustrnlen() function.
qustrnlen() is just qustrchr(), like qstrnlen() is just memchr(). But it
is introduced as a separate function so we could change implementation
if we ever wished to, plus QStringView is only forward-declared at this
point.
Change-Id: Ieab617d69f3b4b54ab30fffd175c560d926db1c3
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is not q20::is_constant_evaluated() because it does not replace
that for all compilers. Instead, it's our own version of it that may
return false even in constant contexts. However, for the majority of our
users, it will work even in C++17 mode.
Updated QStringView and QAnyStringView to use it, which are the only two
places in all of Qt that used std::is_constant_evaluated().
Change-Id: Ieab617d69f3b4b54ab30fffd175c50c517589226
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Because GCC isn't really working them out at compile time. First, for
both lengthHelperPointer(), they don't get called on string literals
such as
return QStringView(u"Hello");
because the type hasn't decayed to a pointer, but is instead a
char16_t[6]. No one writes
constexpr auto str = u"Hello";
return QStringView(str);
Second, even when you do write that, GCC is emitting the code to search
for the null or non-ASCII byte at runtime, instead of pre-calculating
it. That's not worth it because the code is not vectorized, even at -O3
and with a long string. Instead, let it get the length at runtime with
QtPrivate::qustrlen(), which has vector code.
Drive-by fix the QAnyStringView::lengthPointerHelper() to be constexpr,
avoiding the same GCC warning that was fixed for QStringView in commit
4fd4082c3a.
Change-Id: Ieab617d69f3b4b54ab30fffd175c505cb66eac02
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Other parts of the code are expecting int.
Pick-to: 6.6 6.5
Change-Id: Iea73412c874adb2e6589e9b11607f313e1747d19
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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.
Pick-to: 6.6
Change-Id: I99b57335003d06af227f2a7078560c2a483b049b
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
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.
Pick-to: 6.6
Change-Id: Ib1e1b7a745b236e1d137a1e7daf1248f1572e184
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
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.
Pick-to: 6.5 6.6
Change-Id: If071bb64f269ce16886206df05eb9f27d260bf15
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>