This is for internal use, QRhiShaderResourceBinding does not need
to have the data() getters. The backends can use any internal means
to access this, no need to have the getters in the frontend just for
that.
Now, Qt Quick 3D has a special case of accessing this, hence keeping
the two getters for now, to be removed in a follow up once that repo
updates.
While we are at it, share and reuse the sorting function.
Change-Id: Ia2308af79863c72ca65024ce6c00531d0256a2cb
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Also bring all list-like data to the same level when it comes
to the interface exposed in QRhi*.
Change-Id: I90296a49ff1f52c1ce4e787167c99006fab3c4c3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
This does not really belong here as a built-in feature, esp.
considering that such testing is relevant for other backends
as well.
Change-Id: Ifbe3b8c6a430aacb9fcbdabf0e3761b14c48decc
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The QtSql for Mimer SQL sqldriver makes it possible to work with the
Mimer SQL database on different plattforms. There are drivers for
several other databases in QtSql and a driver for Mimer SQL will
benefit many users.
To build the Mimer SQL driver, download Mimer SQL from
https://developer.mimer.com
[ChangeLog][QtSql]
Added a QtSql plugin to work with the Mimer SQL database
Fixes: QTBUG-111219
Change-Id: Id6ba5de4de01189d0516ffbfa89efcb0d013115f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Drive-by change: use UTF-16 instead of UTF-8 for Eastern Arabic
Numerals, both are not human-readable but UTF-16 is one code point
instead of the two for UTF-8, less \x.
Pick-to: 6.5
Change-Id: I721f3989b7d776ddc4f9d337b21dca9d398fcc0d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Constructing from const char* etc is already covered by
constructorQByteArray.
I took a guess that the "// b(10)" comment is about testing constructing
a QString from a QChar[] that has an explicit \0 charcater. I tried
finding what the initial intent was but the trail went cold at the
"Initial import from the monolithic Qt" commit.
Pick-to: 6.5
Change-Id: I15bcdb24e55286eb6cd3056af0714a1eed581635
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Increase to 16GB from 3.5GB. Increase to 6GB was not enough.
Increase to 16GB fixed tst_QByteArrayLarge cases failures.
Task-number: QTQAINFRA-5391
Task-number: QTBUG-108832
Pick-to: 6.5
Change-Id: I97e263fbc2caa7908c706d1c683a4fa868afa7b6
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
Adding the toolbar to the main window leaves it up to the main window
how to handle ownership and placement of the toolbar.
Pick-to: 6.5
Change-Id: Id429cbad9d5973931a86fcb899684e3651694fbb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There is concern about string-based connect() source compatibility in
the case that a signal argument has a different type name.
Amends bc857f466d
Change-Id: I2618b8c5f62b39717e4f7043d07168e808390b1d
Pick-to: 6.5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If the application executable was built against a pre-macOS 11 SDK, macOS
will report its version as 10.16 on every OS from macOS 11 and up, for
compatibility reasons.
From Qt 6.2 and up, we require at least Xcode 12 with the macOS 11 SDK
to build Qt applications, so normally this should not be an issue, but
in the case where the Qt 'app' is a plugin library hosted by a third
party host application, the host application determines the behavior,
and we might end up in the compatibility situation after all.
However, since the Qt app was built against at least the macOS 11 SDK,
we know that it can/should handle the new version number scheme, and
we can resolve the real version number for QOperatingSystemVersion.
We do that by launching the sysctl binary with the SYSTEM_VERSION_COMPAT
environment variable set to 0, which is the supported way of disabling
the compatibility mode.
Now that we have the real version number we can use that for the
deployment target check via qt_apple_check_os_version(), but we
still need to account for possible failures in reading the plist
file.
We can also simplify the QOperatingSystemVersion::MacOSBigSur
definition, now that we always know the app the should be able
to handle major versions above 10.
Pick-to: 6.5 6.4 6.2
Task-number: QTBUG-111114
Change-Id: I2a2756381c31b195f7b8800c5008a87b37114080
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Otherwise, double-click recognition will fail.
Use QEvent::clone when possible, or set the timestamp explicitly when
not.
As a drive-by, remove some long-dead code in affected code lines.
Fixes: QTBUG-102010
Pick-to: 6.5 6.4 6.2
Change-Id: I882bf6e8090bf6f182b7a0a3c62aa3a4c8db2e14
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Most keyboards today do not have a dedicated Meta key. Instead, they may
have a Win key (Windows logo, Penguin logo, etc), which is delivered by
evdev as e.g. KEY_LEFTMETA, but then mapped by libxcbcommon to LWIN
via the default config from xkeyboard-config:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/keycodes/evdev#L203
and then mapped further to Super_L
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/symbols/pc#L24
which is the key symbol that we in Qt see.
As it is common to use Qt::Key_Meta in keyboard shortcuts, it would
be useful if the Win key resulted in key events as if a dedicated Meta
key had been pressed.
This is already something we do for X11, where we consume the events
from xkbcommon, but then use X-specific heuristics to determine if
there is an actual Meta key, and if not, we assume Super/Hyper is Meta.
For plain xkbcommon, we don't have enough information to do the same
kind of heuristics, so we've previously defaulted to not treating
Super/Hyper as Meta. But, as the above xkeyboard-config configs show,
a saner default would be to assume that there is no Meta key, and do
the same mapping as we do for X11 for all consumers of xkbcommon,
such as Wayland and EGLFS.
This does mean that clients that were relying on dedicated Super or
Hyper keys producing Qt::Key_Super or Qt::Key_Hyper will no longer
see these keys being pressed.
[ChangeLog][QtGui][Linux/Wayland][Linux/Yocto] Super ("Win" key) and
Hyper keys will no longer produce the corresponding Qt::Key_Super or
Qt::Key_Hyper key events, but will instead be mapped to Qt::Key_Meta
and result in Qt::MetaModifier being set.
Fixes: QTBUG-62102
Change-Id: Ied4c8b60a0639e87116ab70c7e40d4082f52b18d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Replace local built-time enabled macro with a logging category.
As a drive-by, move QDebug streaming operator into the anonymous
namespace to prevent external linkage, break some excessively long
lines, and remove dead code.
Task-number: QTBUG-102010
Pick-to: 6.5 6.4 6.2
Change-Id: I49d212ee4a66a3eabfa5567f6c8d9674ffbb8880
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The [first, first+n) and [out, out+n) ranges cannot possibly overlap, as
by definition the former contains live objects while the latter points
into uninitialized storage. So we can use memcpy here, and not memmove.
Change-Id: I4a1b39f73ffa67915c5252938554f45f4444293e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I.e. the second arg to QCOMPARE isn't what's being tested.
Drive-by changes:
- More _L1 usage, less blocky and easier to read
- QCOMPARE's second arg can be a View, it is smart enough and can
compare them just fine
- Replace a "//15 chars" comment with a QCOMPARE check
Pick-to: 6.5
Change-Id: I4f4b84b16b543df37b0ba2f9dd781b045b2ed397
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Document the potential issue caused by using QT_ANDROID_EXTRA_LIBS from
the project build tree.
Inspired by QTBUG-111173.
Pick-to: 6.5
Change-Id: I39fcda6e19b15eb13a390978230944dad41ec8d1
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
As of macOS 10.14 the keyboard assistant background is shipped as part
of the compiled asset catalog of the app, so looking it up via a URL
will fail.
Instead we look it up via NSBundle's dedicated image lookup function,
which handles both cases.
The logic has also been moved to qwizard.cpp, since the additional
plumbing via QPlatformNativeInterface was unnecessary.
The keyboard assistant itself no longer shows the background image
as of macOS 12, so we might consider doing the same, but the design
of the assistant has also changed significantly, so as long as our
QWizard layout looks like the old keyboard assistant we keep the
background as well.
Pick-to: 6.5 6.2
Change-Id: I7d42dd79b285f3518837458864bca6bc353b3b6d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This reverts commit 545400addd.
Reason for revert: Adding NO_CMAKE_PACKAGE_REGISTRY doesn't resolve the initial issue. So reverting this change as redundant.
Change-Id: I284600d6f0e0f2408a7a8b31827251dad4c73eba
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This feature should not be needed in most wasm applications.
Disabling it by default can save ~50KB in QtQuick apps.
Task-number: QTBUG-110843
Change-Id: Iac0a51bfd016db1da40b59ed32e3faf6ad4267e0
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Application delivered via the macOS or iOS App Store might have their
libraries encrypted, in which case we can not read any of the sections
of the binary until it has been dlopened.
This was causing issues for our plugin loading code, which assumed we
could read the .qtmetadata section of a yet to be loaded plugin to
determine its suitability, before loading it.
We now detect whether a library is encrypted during the Mach-O parsing,
and propagate this back to QLibraryPrivate::updatePluginState(),
which can handle the case by explicitly loading the library before
continuing with metadata validation. We still ensure that the library
has a .qtmetadata section, so that we don't need to dlopen any random
library in our path.
This does mean that we will potentially load more plugins than we
need, and since the Qt version validation happens as part of meta
data validation, we might dlopen() incompatible plugins, but it's
expected that in an App Store deployment scenario you control both
the versioning and set of shipped plugins, so this should not be
an issue in practice.
As encrypted libraries are only produced for apps that are fully
published to the App Store, and then deployed via MDM, VPP, or
Apple Configurator 2, we don't have an easy way to test this,
but the existing code paths should be unaffected, and hopefully
this patch improves the situation for the encrypted library case.
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: Iff733505f7067ce5571854ea978bc95e8376e347
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The QSslCertificate ctor is somewhat expensive, especially when we are
shutting down. By using optional<> we simply reset() it and no longer
need to create a new, valid, certificate.
Pick-to: 6.5 6.4 6.2
Task-number: QTBUG-102474
Change-Id: I514433b0d380dd3ceabbed3a6164f7e3efc490c7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
- Port macros to QTest data rows in separate unittests
- Move DOUBLE_TEST-related data to toDouble() unittest
- Drop one redundant unittest:
QTest::newRow("const-charstar") << (const char*)0;
Pick-to: 6.5
Change-Id: Ie809895e9f5d58c2d3ec419689f409b55e24fcf7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
After commit b5a54d488c, we now use QCollator and so no toLower()
when caching the filename, we can re-use it from the cache after
sorting.
Change-Id: I8602a11c6f68cfe61db3ec6330596066cd257dab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
And switch to using test data rows (rooting out two macros in the
process).
Pick-to: 6.5
Change-Id: Ib31e6b59f90f0983c0efc4bef7cb246aedfcab5b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change test data to compile with NO_CAST_FROM_ASCII uncoditionally where
casting from ASCII isn't what's being tested by a unittest.
The goal is to add a variant of tst_qstring that is compiled with
QT_NO_CAST_FROM_ASCII so that the unittests cover that code path too.
The commits are split into smaller chunks (where there is a common
link between changed code, that code is put in a commit, otherwise I
kept the number of changed lines below ~150) to make reviewing them
easier.
Pick-to: 6.5
Change-Id: I14256f1bde7749a3023753dbb7ed8be72cb6bc14
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's possible for time_t to overflow and time() to thus fail, so check
against that. We don't need to think about the last second of 1969 for
this, as that won't be the current time for anyone running this code.
Change-Id: I14f34d5d3e2ab9713593fcd06d6771e1d7f357ee
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add exclusions for issues that are likely not fixable
(3rd party code, X11 define clashes, etc) in 3rd party,
tools and plugins.
Pick-to: 6.5
Task-number: QTBUG-109394
Done-with: Amir Masoud Abdol <amir.abdol@qt.io>
Change-Id: I698c004201a76a48389271c130e44fba20f5adf7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Amends 17c1ebf8bf, after which dragEnabled
item views toggled selection on click rather than on press. If the edit
trigger included SelectedClicked at the same time, then Ctrl-Clicking a
selected item would start editing the item, instead of toggling
selection.
Fix this by ignoring clicks with modifier when evaluating whether
editing should start.
Extend the mouseSelection test case by including a column for the
editTrigger, and cover the respective combinations.
Fixes: QTBUG-111131
Pick-to: 6.5 6.4 6.2
Change-Id: I9605f9b3d5a49e292551a34c3c4c7a5f9ecb2a89
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The bearer code hasn't been in Qt for some years.
Pick-to: 6.5 6.4 6.2
Change-Id: Id69ad1ce5035a0970f3507d4b6ba4a5549bf1d6c
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
