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>
`QStatusBar::removeWidget` was hiding the wrong widget (the next one),
since the `removeAt` call changed the item that the `item` variable
is referencing.
This fixes a regression in Qt 6.3.0 (7166a82844).
Pick-to: 6.5 6.4
Change-Id: I9977b47e6208f8d451ff1037bcb9f4e8414cb431
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thorbjørn Lindeijer <bjorn@lindeijer.nl>
Remove the deprecated timeStamp argument from the parseHeader function.
Fix signed/unsigned comparison between file size and buffer size.
User the correct oder when initializing variables.
Pick-to: 6.5
Change-Id: I483cc175c9aaf42917053b6731833e1b4f5cad3a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This will cause coin to test the newly integrated HEAD for the
given modules. In case a failure occurs in the check a message
in gerrit is sent to the commits which were integrated in the
HEAD.
Change-Id: I656316c7cceb126ccf570fd3db3f7fd2b22cc4fa
Reviewed-by: Simo Fält <simo.falt@qt.io>
using fileName is more correct in this case.
Task-number: QTBUG-98974
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: I7c547bfc1c2321d4817dc087d3e962dbc2a0b7fd
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
There are two problems in emplace_impl() (the same code exists as
rvalue insert() since 5.10):
First, the old code updated size() at the end of the function.
However, if, after constructing the new end element, one of the
subsequent move-assignments fail (throws), then the class invariant
that size() be the number of alive elements in the container is
broken, with the immediate consequence that the QVLA dtor would not
destroy this element, but surely other unpleasantness (UB) that the
C++ lifetime rules decide to throw our way.
Similarly, in the trivially-relocatable case, the memmove() starts the
life-time of the new end object, so if the following placement new
fails, we're in the same situation.
The latter case is worse, though, since here we leave *b in some weird
zombie state: the memmove() effectively ended its lifetime in the
sense that one mustn't call the destructor on the source object after
trivial relocation, but C++ doesn't agree and QVLA's dtor will happily
call b->~T() as part of its cleanup.
The other ugly thing is that we're using placement new into an object
that C++ says is still alive. QString is trivially relocatable, but
not trivially copyable, so we can't end a QString's lifetime by
placement-new'ing a new QString instance into it without first having
ended the old object's lifetime.
The fix for both of these is, fortunately, the same: It's a rotate!™
By using emplace_back() + std::rotate(), we always place the new
object in a spot that didn't contain an alive object (in the C++
sense) before, we always update the size() right after doing so,
maintaining that invariant, and we then rotate() it into place, which
doesn't leave zombie objects around.
std::rotate() is such a fundamental algorithm that we should trust the
STL implementors to have optimized it well:
https://stackoverflow.com/questions/21160875/why-is-stdrotate-so-fast
We know we can do better only for trivially-relocatable, but
non-trivially-copyable types (ex: QString), so in order to not lose
the memmove() optimization, we now fall back to std::rotate on raw
memory for that case.
Amends dd58ddd5d9.
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: Iacce4488ca649502861e0ed4e084c9fad38cab47
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
qmainwindowlayout.cpp:(.text+0x2976): undefined reference to
`_q_tb_tabBarShapeFrom(QTabWidget::TabShape, QTabWidget::TabPosition)'
_q_tb_tabBarShapeFrom is implemented in qmdiarea.cpp which is not
compiled when the feature mdiarea is disabled.
Pick-to: 6.5
Change-Id: Ib0c6447b9381b8ce01542fabf831a9db7f5e6675
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Its only client was QMainWindow, but that use was removed in
3b8b47db6a and replaced with a
call to setContentBorderEnabled.
This effectively reverts 0caaf9966a.
Pick-to: 6.5
Change-Id: Iaba4d5fd9256632b4a3b935e3fb30d7f5c39851e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This reverts commit 854986836a.
This reverts commit 392d9a5419.
Turns out that enabling this option is now breaking the Qt build,
because tools that are called by the Qt build cannot run anymore due to
the lack of rpaths.
Before, QT_DISABLE_RPATH was simply turning off Qt's additional rpaths
but left CMake's rpath defaults intact.
To implement a working -no-rpath switch we must add Linux and macOS code
paths to _qt_internal_generate_tool_command_wrapper and set
LD_LIBRARY_PATH/DYLD_LIBRARY_PATH and friends.
Pick-to: 6.5
Fixes: QTBUG-110816
Change-Id: I021d5e6cd775cbe5b2411d6771ab2545cb04f799
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
