The digit-grouping and fractional-part separators need to be distinct
for parsing to be able to distinguish between two thousand and one vs
two and one thousandth. Thakfully ldml.py asserted this, so caught the
glitch in CLDR v43's data where mn_Mong_MN over-rode mn's decimal, but
not group, and thereby clashed with group. Fortunately the over-ride
is marked as draft="contributed" so we can back out of the collision
and limit the selection to draft="approved" values (but only when
there *is* such a conflict, as plenty of locales have (compatible)
draft data), thereby ignoring the conflicting contribution.
Brought to the attention of cldr-users at:
https://groups.google.com/a/unicode.org/g/cldr-users/c/6kW9kC6fz3g
hopefully that'll lead to a saner resolution at v44.
Task-number: QTBUG-111550
Change-Id: I1332486e60481cb4494446c0c87d89d74bd317d4
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
(cherry picked from commit 8a762c6f0f)
From CLDR v43, "The parentLocale elements now have an optional
component attribute, with a value of segmentations or
collations. These should be used for inheritance for those respective
elements." Since we aren't extracting collation or segmentation data
for the present, omit these elements from the scan for parentLocale
information.
Task-number: QTBUG-111550
Change-Id: I42871929f539c1852471812801953f2fc8be0e8a
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
(cherry picked from commit 615047e98f)
The script and territory to exclude from reports about unused ones
were swapped, so we excluded a territory from the script list (which
didn't contain it anyway) and vice versa.
The test for whether to report used the non-existent .territories
attribute by mistake for .__territories
Change-Id: I29e9d9f8f34883d7c3a5ac15470d9e7a0366e3db
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
(cherry picked from commit 37c5a9f20b)
Amends commit 9a8b9473d5 - apparently
the enumdata.py entries were tidied up after the data had been
generated, leading to them being inconsistent (and I missed that in
review). That, in turn, meant the next update would have changed the
public API enum members, backwards-incompatibly; so make enumdata.py
consistent with the released public API. We'll be tidying the order up
at Qt 7 in any case.
Task-number: QTBUG-110333
Change-Id: I3eed2924ce8b69deb552e923d9b0dc142c5f3a65
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
(cherry picked from commit 4e23da9086)
Mark the module are Q_FOREACH-free, so it stays that way.
These two instances are risk-free, because the loop is over local
variables that the loop bodies clearly do not touch, so the safety
copy that Q_FOREACH takes is not required here.
Change-Id: Ida3c1d51c661d77a59a2ad105e080c3c9b66c53f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit c91146b9ef)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Well, except that the ownership of the slot object here is actually
shared between the PermissionReceiver and the lambda passed to
QPermission::Private::requestPermission(), which eventually may hand
ownership over to QMetaCallEvent, so we can't really use
SlotObjUniquePtr.
While we can, of course, manually copy and call ref(), even if the
slot-object is stored in a SlotObjUniquePtr, unfortunately, the lambda
is subsequently stored in a std::function, which infamously cannot
hold move-only objects, so we actually need something copyable.
So grasp the nettle and implement a SlotObjSharedPtr.
I was originally planning to just make this a typedef for
QIntrusiveSharedPointer, but that's not in dev, yet, let alone 6.5, to
which we're picking this, and there was always this nagging impedance
mismatch between the QIntrusiveSharedPointer behavior, inherited from
it's Q(Explicitly)SharedPointer roots, on the one hand, to always
ref() in the constructor from raw pointer, and, OTOH, QSlotObjectBase
starting its life with a ref-count of one (1) (not zero (0), like
QSharedData).
I eventually found the (elegant, if I may say so myself) solution to
just not provide a constructor from raw pointer, only one from
SlotObjUniquePtr, which, granted, has the same issue, but which is, by
now, probably, hopefully, more fully grasped by QtCore regulars, and so
we can piggy-back on that for SlotObjSharedPtr's constructor
semantics.
Add a comment nevertheless.
Inside the lambda, we could theoretically move the slotObj into
QMetaCallEvent::create(), after adding such conversion to
SlotObjSharedPtr, but that would require making the lambda mutable,
and seeing as it's stored in a std::function and copied around, I was
not ready to make that change just yet.
As a drive-by, make PermissionReceiver's constructor explicit.
Fixes: QTBUG-115330
Change-Id: I4e0cec13d19a19eeec31e4101ce289d07c92ce46
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit f141108887)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QAtomicInt::ref() returns bool, not int, so do the same in our ref().
As a drive-by, drop the superfluous inline keyword.
Change-Id: I60712df3640b67dfd857355d364e0fc5a3a40650
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 902063628f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This is the only way to detect, and act upon, the addition of the
virtual function in other Qt modules.
Amends a4ca9e8065.
Task-number: QTBUG-97482
Task-number: QTBUG-115691
Change-Id: Id32fdd3d8af1fced17983dd104318645a5578b8c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit f91588923b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It's a) not needed, because qstringbuilder.h simply just defines op%
and not op+ when these defines are not set and b) surprising for users
that they have to include <qstringbuilder.h> if they want to use op%
without also setting one of these defines. Finally, it just throws
readers of the code off the track for no good reason.
So, drop the external guards for qtringbuilder.h in qstring.h and
qstringconverter.h.
Task-number: QTBUG-114208
Change-Id: I00b3e405d905d319437c32a7253b39de1625d096
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
(cherry picked from commit 15ff5bafa0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
`\target`s generate a span where they occur. If they occur outside a
table cell, QDoc generates illformed html. Fix such instances by moving
the offending line into the table cell they target.
Task-number: QTBUG-115247
Change-Id: I677e909ec73a6d0af8195d88d23581d8dd97c6e5
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
(cherry picked from commit 78bc1a9a25)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QByteArray::assign() re-uses existing unshared capacity(), if any, and
is therefore potentially more efficient than '= QByteArray(~)' (and
never slower).
Task-number: QTBUG-106201
Change-Id: I5e5114064c8aaa23892e95c235335632d7c5cd0a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit d7d15c1a47)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Remove old files from the output location before saving new ones.
Change-Id: I75181126c6c920e13951e9a46a6be1c666d457fe
Reviewed-by: Antti Määttä <antti.maatta@qt.io>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
(cherry picked from commit c6ab516f71)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QMetaType does not own the interface from which it is constructed.
Consequently, we end up with a memory leak.
This is not a huge issue, given that the map of meta-types is static,
and the application is about to be close when can discard it anyway, but
it causes avoidable sanitizer warnings, which are annoying when
debugging more severe memory leaks.
Change-Id: Ifee3f4e19835536f4a6cfa4f6866ab621581ad4f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 4c1df115ec)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Fixes an issue with generated code where the name of an enclosing
namespace is identical to an enum class type, when Q_ENUM_NS is used.
Consider:
namespace a {
Q_NAMESPACE
namespace b {
enum class b { Key, Key2 };
Q_ENUM_NS(b);
}
}
moc generated code such as:
Q_CONSTINIT const QMetaObject a:🅱️:staticMetaObject = { {
...
qt_incomplete_metaTypeArray<qt_meta_stringdata_CLASSaSCOPEbENDCLASS_t,
// enum 'TestEnum'
QtPrivate::TypeAndForceComplete<b::b, std::true_type>,
// Q_OBJECT / Q_GADGET
QtPrivate::TypeAndForceComplete<void, std::true_type>
>,
nullptr
} };
which confused the compiler:
error: ‘b’ is not a member of ‘a:🅱️:b
83 | QtPrivate::TypeAndForceComplete<b::b, std::true_type>,
Fixes: QTBUG-112996
Change-Id: I37aee83c32efe96cc9d6c2bd0bdb9ba80bb7b8a7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 7779400ba6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If module depends on some module Private part only the sync_headers
dependencies from this public part of this Private module is skipped.
Check if the module is Private and use the public module to read the
_qt_internal_sync_headers_target property.
Amends 0006a564c8
Fixes: QTBUG-115712
Change-Id: I4678e2a6c9ec8f80862a97d48f0a3b4214ae2307
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit d7a3733056)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use [&] instead and remove overparenthefication as a drive-by.
Amends c888e3922d.
Change-Id: Ic7930d5011c247122a1b3396ea0d6a9a2d6107de
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
(cherry picked from commit 19c70f40d2)
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QTreeView::visualRect() returns a given model index's visual rectangle.
The method is used to toggle the background during hovering.
The previous implementation included the row indicator, when the first
row section was hovered. When it was unhovered, the row indicator
remained highlighted, until the mouse had left the view port.
The reason is, that the highlighting implementation changed the
rectangle returned for the first section, to include the row indicator.
The implementation for neutralising a highlighted section relies on
QAbstractItemViewPrivate::setHoverIndex() and
QAbstractItemView::update(). These methods don't know about the row
indicator to be included, and therefore do not update() its rectangle.
As a consequence, the correct background gets painted but not updated
on the screen.
This patch moves the calculation of the visual rectangle to a new
QTreeViewPrivate::visualRect_impl(). In addition to the model index,
the new method expects an enum argument, representing the calculation
rule:
- SingleSection: Calculate the rectangle of the given section.
- FullRow: Returns the rectangle of the entire row, regardless of the
index's column.
- AddRowIndiCatorToFirstCulumn: Adds the row indicator to the rect,
if the model index points to the first column.
The patch updates all calls within QTreeView, to use the private method
with the right calculation rule for the use case at hand. It elminates
manual (and repeated) modifications of the return value.
The patch implements QAbstractItemViewPrivate::visualRect(), which
returns QAbstractItemView::visualRect(). It is overridden in
QTreeViewPrivate, so that QAbstractItemViewPrivate::setHoverIndex()
and QAbstractItemView receive the rectangle including row indicator.
As a drive-by, several local variables have been constified and/or
renamed to indicative variable names.
Fixes: QTBUG-115149
Change-Id: I4838bcf744f87d8cfb259c5d8758fb65e091e9fe
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit d35e8ad754)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The blacklisted test does not crash, as its expected output indeed shows.
Change-Id: I07522a7d065b5f39620975a3546bcd156024c41d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
(cherry picked from commit 5993480b69)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Introduce QT_SUPPORTS_INT128 and QT_NO_INT128 marcos to handle 128-bit
types. These macros allow to undef Qt's own 128-bit types and the
related code, but keep the compiler definitions unchanged.
This is required for Qt Bluetooth, where we need to use
QT_BLUETOOTH_REMOVED_SINCE to get rid of the APIs using
QtBluetooth-specific struct quint128 which clashes with the 128-bit
types. The idea is to use QT_NO_INT128 in Qt Bluetooth's
removed_api.cpp instead of directly undef'ing __SIZEOF_INT128__,
because the latter is UB.
This commit amends befda1acca.
Change-Id: Ia2c110b5744c3aaa53eda39fb44984cf5a01fac2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit eb0abd9789)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In porting the selftest machinery to Catch2 in 24e83de8d1 we
accidentally added an unconditional early return when determining
whether to check for unexpected stderr output, resulting in not
checking error output on any platform.
The return statement has now been moved into the Q_CC_MINGW
condition, but as we now seem to have similar issues on macOS
and Linux with some of the tests outputting "Received signal 6
(SIGABRT)" as we do for QEMU, we need to add a few more explicit
early return conditions to the function.
Change-Id: I7a25f000843b5f1003a5db883f08285185046b46
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit 118f2210c6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Commit ca54b741d6 used the internal
has_operator_equal (and commit 01d94760d8
copied that for has_operator_less_than) instead of using the recursive
expander that was being used here. That assumed that the contained type
in std::optional would always be the last final check, which is an
incorrect assumption.
Fixes: QTBUG-115646
Change-Id: Ifbf974a4d10745b099b1fffd177702934bec27ff
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit cff13c2417)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Replicate qvulkaninstance.h's logic. The idea being to allow
to compile code that uses QRhi (so includes qrhi.h) with a pre-built
Qt that was built with Vulkan support, but there is no Vulkan SDK
(and so vulkan.h) on the developer's system. Normally this is not
something we care about, e.g. compiling an application using
QVulkanInstance or any other Vulkan functionality implies one has
to have the SDK installed or at least the headers available in one
way or another.
However, including qrhi.h (and so qrhi_platform.h) happens in some
cases in applications that do not themselves initialize a QRhi,
i.e. they do not care about the QRhiVulkan* structs, because
they only ever use a QRhi retrieved e.g. from the QQuickWindow.
Design Studio is one example. To allow building DS against a Qt
that is Vulkan-enabled (e.g. the official Qt releases) but in
an environment that has no Vulkan headers, we skip the QRhiVulkan*
stuff when there is no vulkan.h available.
Change-Id: Ic81250e6c90939a38f79cab1438fbb9f483f56df
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io>
(cherry picked from commit c6fce818db)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It is part of a solution to produce notarizable binaries for
application using Qt WebEngine.
Task-number: QTBUG-99555
Change-Id: Ice0bbcfb12829906328f55158b0c37f03878f17c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit ebb361ee3f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Activity.getReferrer does not only return app IDs but also URLs if
Intent.EXTRA_REFERRER is set on the Intent. In the case of Chrome the referrer
is set to the website triggering the Intent. To improve the detection of the
calling app we check first if the browser specific
Browser.EXTRAS_APPLICATION_ID is set. If it is not set we fall back to
Intent.getReferrer.
Change-Id: I33d1edd52de98486d9616713e531ea20ada87bcb
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 7012bea614)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
in QXcbAtom::initializeAllAtoms().
See also the example in
https://manpages.debian.org/testing/libxcb-doc/xcb_intern_atom_reply.3.en.html
Fixes: QTBUG-115599
Change-Id: I6590fe1aa11deec7fef7ce6d8f5c49a71d636648
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 552e3b9b78)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As a result of d8bbb5ee0e, we
were no longer calling QDialog::done(), which users may have
overridden.
We now pull out the dialog code to determine whether to
emit accepted/rejected directly in done(), so that we
can go back to calling QDialog::done().
Change-Id: Ie08270123d61d9010acd8c989b66986f71960ad0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 1f70c073d4)
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The native dialog helper is populated with buttons based on the message
box buttons, which are still represented as QAbstractButtons, either
by adding custom buttons, or by turning QMessageBox::StandardButton
into QAbstractButton.
To ensure as little difference as possible between the native and
non-native backed dialogs, we plumb the dialog helper clicks back
to the corresponding QAbstractButton. We were already doing this
partially for custom dialog buttons, but now we also do it for
standard buttons.
As the click() will plumb back to _q_buttonClicked, which calls
setClickedButton to finalize the dialog, we don't need to do
this explicitly anymore.
For custom buttons it now means the result() of the message box
will be the custom button's index, not its role, but the result
in this case is documented to be an opaque value, and it's best
to keep these the same for native and non-native dialogs.
Change-Id: I5fe3b28e4c4ed879775610103cd1b591b3353f7e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 4a4283e3e9)
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In d8bbb5ee0e we started respecting the
button roles of buttons added to QMessageBox, by emitting accepted()
and rejected() if the appropriate roles were found.
Unfortunately this only touched the QMessageBoxPrivate::_q_buttonClicked
code path, for non-native dialogs, leaving the code path for native
dialogs in QMessageBoxPrivate::_q_clicked alone.
We now follow the same approach for the native dialogs as for the
non-native ones, by calling QMessageBoxPrivate::close() and
QMessageBoxPrivate::finalize() explicitly, instead of going
via QDialog::done(). This allows us to pass a dialog code
to finalize().
One side effect of the original change was that overriding
QDialog::done() for non-native dialogs no longer had any effect,
as we were using lower level plumbing. Since we now align with
the original change for native dialogs, we will adopt the same
limitation, but this will be fixed in a follow up for both
cases.
The callback code for custom buttons in native dialogs could also
use some alignment with the non-native path, but this is also
left for a follow up.
Fixes: QTBUG-113685
Change-Id: Iea03a0007f884d6c7f11d2bd891446bdaa5ddc67
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Erik Verbruggen <erik.verbruggen@me.com>
(cherry picked from commit 6da1ecc8c2)
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
After 449b45ff34 we emit aboutToQuit
before quitting the main event loop, matching the documentation and
semantics of "about to". Clarify this in the documentation, so that
client do not rely on a missing main event loop to trigger processing
of root level deleteLater() calls in a nested event loop.
Change-Id: Ifd116394a1960814edf69f20c5aaff6a8e5cfc24
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 04b619d950)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The Freedesktop Icon Theme Specification [1] describes that,
if a theme does not specify anything for its 'Inherits' key,
"implementations are required to add the 'hicolor' theme to
the inheritance tree. An implementation may optionally add
other default themes in between the last specified theme and
the hicolor theme."
And later, when describing the lookup algorithm, that "The
lookup is done first in the current theme, and then recursively
in each of the current theme's parents, and finally in the
default theme called 'hicolor' (implementations may add more
default themes before 'hicolor', but 'hicolor' must be last)".
But it doesn't explicitly describe the behavior when a theme
does specify a list of inherited themes via the 'Inherits' key,
and this list explicitly includes 'hicolor'.
In that case, our custom fallback theme, which we inject after
the theme's explicit parents, will be prioritized after 'hicolor'.
As it's likely that the theme author added 'hicolor' to their
parent list to ensure that 'hicolor' is at some point consulted,
but didn't intent it to be priorized, and that the spec puts focus
on 'hicolor' being last, it seems reasonable that we can move the
'hicolor' theme to the end of the fallback list, and as a result
always prioritize fallbackThemeName() over 'hicolor'.
[ChangeLog][QtGui][QIcon] The 'hicolor' theme will now always be
prioritized last when looking up fallback themes, even if
explicitly declared as a theme parent in a theme.
[1] https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
Change-Id: I76538e4e7e9e395f9e5a38e704c60fb6b9688885
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit e603661c48)
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Was missing for some reason when this got added in 6.4.
Change-Id: I4f8b780c7119649688d8d8a197e8ef59730b0b61
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit cdae120f7f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
caps.apiVersion is inst->apiVersion() limited by the version the
physical device reports. Therefore, use caps.apiVersion when
setting up the memory allocator, like it is done everywhere else.
This is expected prevent vma init failures on lavapipe in some Linux
distros.
Change-Id: I4e693820c95a5e0174846afb20e42aadd56034d6
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit f9d473ac72)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
One may very well force a 3D API not functional. In this case there will
be no QRhi. A bunch of warnings will be printed (which is good), but
then flush() should not do anything, and that was not handled before.
Change-Id: I82139070311152c959d39a553842f4462d8e7811
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit 108b101441)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If a callback deleteLaters a QRhiResource that should still be
handled and not left unreleased. Swap the order.
Change-Id: I8419a28a9db5bb59f768ab5820dfaf593464d6d2
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit d907f1aa92)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Showing code that cannot possibly compile is bad practice.
(vkAllocateCommandBuffers is in QVulkanDeviceFunctions, not
QVulkanFunctions)
Rather use a member function that is actually in QVulkanFunctions.
Change-Id: I3063a8a229152144ce866e915eb4c14ecc58e9ce
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit e8e9c287ec)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Ironically enough when the old macOS 13 problem is no longer occurring
(at least on an M1 Mini with 13.2.1), so the OS version based
differentiation could likely be removed, there are now reports about
problems with old Intel hardware and earlier OS versions.
Therefore, get rid of the OS version based logic, and rather add
a global flag that is enabled unconditionally for now, which
disables MTLBinaryArchive usage altogether.
How much we lose is not very clear anyway. The OS performs its
own persistent caching (most likely), hidden from applications.
Thus what we lose really is the fine grained control over the
data (e.g. specifying a custom storage file via
QQuickGraphicsConfiguration), with the possibility of pre-seeding
for the first run. As the performance of subsequent runs is less
likely to change in any significant way, this is seen as not
a big deal for Apple hardware in general so we might just live
with this. (and on macOS 13+ this was already crippled anyway
due to the OS version logic)
Fixes: QTBUG-114338
Task-number: QTBUG-108216
Change-Id: If7b908baea2093f6882674ebfbdc18e770d6503e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit fa96e76ab1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Running a Vulkan-based QRhiWidget (upcoming in 6.7) and QQuickWidget
shows the "...does not support OpenGL-only windows" warning which is
pointless nowadays. Since Qt 6.4 RasterGLSurface is not in use,
whereas the surface type can very well be VulkanSurface too.
Change-Id: I790767e683b2a4cffc99cbc38015aca809cf83c5
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 4abf862bca)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Should be no different from MetalSurface and OpenGLSurface.
Change-Id: I529f2904a43e44376e9f2da2489fac57670d954d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit e310bc1646)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
