Strictly speaking, we did want to compare pointers, but char* are
special with QCOMPARE in that the pointed-to strings are compared, not
the pointers. So this wasn't doing what we wanted it to do.
We could static_cast to void* to do it, but subtracting one from the
other also gets us what we want, with simpler code. The drawback is that
if appendToBuffer() ever returns nullptr, we'll print a huge number as
the offset.
Found by Valgrind:
==3769588== Conditional jump or move depends on uninitialised value(s)
==3769588== at 0x483FEDC: strcmp (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3769588== by 0x4C41EB6: qstrcmp(char const*, char const*) (in lib/libQt6Core.so.6.9.0)
==3769588== by 0x48975D8: QTest::compare_string_helper(char const*, char const*, char const*, char const*, char const*, int) (in lib/libQt6Test.so.6.9.0)
==3769588== by 0x12B12A: QTest::qCompare(char*, char*, char const*, char const*, char const*, int) (in tests/auto/corelib/text/qstringconverter/tst_qstringconverter)
==3769588== by 0x10EE94: tst_QStringConverter::invalidConverter() (in tests/auto/corelib/text/qstringconverter/tst_qstringconverter)
Amends c46ee7df57.
Pick-to: 6.7 6.5 6.2
Fixes: QTBUG-126107
Change-Id: I44265a5eb67e47a59fc8fffd17d64051657af529
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 9d5611dc97979dab1932b07f8cfab367c3872d24)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Version 903a83ff7bfc3148e3692e09396f9f3bdc9462ef, fetched on
2024-06-05.
[ChangeLog][Third-Party Code] Updated the public suffix list to upstream
SHA 903a83ff7bfc3148e3692e09396f9f3bdc9462ef.
Pick-to: 6.7 6.5 6.2 5.15
Task-number: QTBUG-126060
Change-Id: I96320b5df1a3573ab9198ad412fc1eca55204c02
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit c0d5c1b2fef140a44b6512ee79ba7fb67187a39c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The ctor is explicit so there should not be an assignment operator op=.
Changing the assignment to = Qt::totally_ordered_wrapper(ptr) is also
possible but if ptr is nullptr, I have to forward declare a pointer as
follow "T *n = nullptr" and then call Qt::totally_ordered_wrapper(n).
So I think adding reset(P) function is better.
Found in API Review.
Change-Id: I0acfcacc97a43f3cf8bfa65b2b16a65cae95b727
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit dc49d84abc35dfbbc4028a5f86017786cff13ae7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Unlike the old Qt::compareThreeWay() overload for raw pointers, the new
overloads for the Qt::totally_ordered_wrapper didn't allow to compare
wrappers of different (but compatible) pointer types (base vs derived).
This patch fixes it.
Ideally the constraints on operators in Qt::totally_ordered_wrapper
should use std::common_type_t, but we hit a bug in VxWorks that
prevents us from using it, so simply demand that the types are
convertible pointers. For now that should be enough, considering
that Qt::totally_ordered_wrapper only expects pointers as wrapped
types.
Found in API Review.
Change-Id: I9f7184468bea3e1f2944ca5347f0b79eded2f4d3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit d73bdec05101b34745156c8cd4ea571f1223ad32)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
compareThreeWay() was supposed to be an operator<=>(), but for C++17.
The idea was that at some point when we unconditionally demand C++20,
people could just replace all the usages of compareThreeWay() with
operator<=>().
However, the Qt::compareThreeWay() overload for pointers is different
from the operator<=>() for pointers, because it is actually using
std::less{} or std::compare_three_way{} to do the comparison, thus
avoiding an UB. This is not bad as such, but can potentially lead to
UB when mass-replacing all compareThreeWay() calls with operator<=>().
To avoid this problem, deprecate the overload, and suggest to use
the Qt::totally_ordered_wrapper together with the respective overload
instead.
Found in API Review.
[ChangeLog][QtCore][QtCompare] Deprecate Qt::compareThreeWay()
overload for pointers.
Change-Id: I9c57871145dc3cb9656d6006db88b48a1553bef4
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit b1ae4334ea11f6942c7ce37a80a3aa98a3447809)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Provide the overloads as free functions in Qt namespace instead of
making them hidden friends of the Qt::totally_ordered_wrapper class,
because they should replace the to-be-deprecated overloads of
Qt::compareThreeWay() for raw pointers, so they should be
easily discoverable.
Also, we treat Qt::compareThreeWay() as a C++17 equivalent of
operator<=>(), so we need to have an overload for pointers (even
if it takes only the wrapped pointers).
Found in API Review.
[ChangeLog][QtCore][QtCompare] Added Qt::compareThreeWay() overloads
for Qt::totally_ordered_wrapper. These overloads do the comparison
using strict total ordering.
Change-Id: I2b5bc542c546330ca78c6284188c8167136a849e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit d6e1df3513c7d5b6e93d68583fc4c1febb7bcd85)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Found more issues:
- quint8 and qint8 (signed and unsigned char) actually match an
integral overload (probably int/uint), and _not_ (char),
- char8_t (only in C++20 builds) and (at least on non-Windows) wchar_t
are incorrectly treated as numeric types,
- qfloat16 breaks if QFLOAT16_IS_NATIVE.
Created a few tasks to track these.
Task-number: QTBUG-126053
Task-number: QTBUG-126054
Task-number: QTBUG-126055
Pick-to: 6.7 6.5 6.2
Change-Id: Iaf64929e3fae257d5dd283f555bb71ea2908cc94
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 967736b96ba06bfdfdf553b2c3720d7adc4a921c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The static QMessageBox APIs taking button texts instead of standard
buttons promises that the return value is 0, 1, or 2. After the change
in b30121041c the return value of exec
for custom buttons was changed (as the documentation says its an opaque
value), which unfortunately affected the deprecated functions.
To fix this, we use the index of the clicked button in the custom
button list, to restore the previous behavior of the deprecated
APIs.
Fixes: QTBUG-125858
Pick-to: 6.7
Change-Id: I96d39e42b64e2b55eab07e2f15df71b94cfe3e6d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit a428c6933565ee8368367534cf306ccc6957f5a5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 5b151ea2d23dc3834180d3ec6495ac5d99cae550)
The previous patch missed the handling of SQL_INT128 in
qIBaseTypeName2().
This amends 373ae6cbd2
Change-Id: I646bd5af23c14761195f9c1089dc4cbbe2e94790
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Andreas Bacher <andi.bacher@outlook.com>
(cherry picked from commit f6bb8f832442a2e70b3d4718fb06807cfe98511b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Change all functions taking a QStringView to take a QAnyStringView and
remove all functions taking a const QStringRef since this can now be
fully handled by the QAnyStringView ones.
This amends f2dba19194 and
993f318014
[ChangeLog][QtSql][QSqlRecord] All functions taking a QString were
changed to take a QAnyStringView.
Change-Id: Ia1c968c4e2a7a93aa26d090ef6605271305c14a6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 6b096271cf0aac38d80f292f8b37edd671a8d17f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Makes sense to collect the stuff in a similarly-named header, and it's
not like any of the QTypeTraits stuff was needed for QTypeInfo.
Makes #include <qtypeinfo.h> _much_ lighter again, at the expense of
qminmax.h now getting <variant>, <tuple> and <optional> instead, but
qminmax.h is much easier to avoid in Qt headers (just use the std
versions) than qtypeinfo.h.
[ChangeLog][QtCore][Potentially Source-Incompatible Changes] The
qtypeinfo.h header no longer transitively includes <optional>, <tuple>
and <variant>.
Task-number: QTBUG-97601
Change-Id: Ied96113f38c1232fef3ec79847ee62f06c68f268
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit b2eb422699118f4ae8370519b4c7bb3fe121beb2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Some compilers do not respect the
QT_WARNING_PUSH
QT_WARNING_DISABLE_DEPRECATED
...
QT_WARNING_POP
incantation, so rewrite the test to use `template <typename X>` as
an Attribute parameter of the macros.
This allows to get rid of annoying warnings when compiling
tst_qcomparehelpers.
Amends de16185068.
Change-Id: I0b3a0f4ad3189d39f5662ce128d5e5f427543393
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit c6feed7e1d8b8ed991a81878c78bb361f038eaf6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The recent change to IANA ID lists extracted for Windows adds new IANA
IDs to various zones and shuffles the order in some cases, leading to
changes in offsets throughout the related tables (and two test-case
that lose an expected entry that was an alias for one of its
others). This is caused by CLDR doing a clean-up of its zone
information, deprecating some old names, combining some synonymous
zones and reversing some aliases to better match the IANA DB. As a
result, some prior expect-fail tests now pass.
The code that reads the tables is insensitive to order after the first
entry in each list; and the first entries only change where they were
CLDR's ID for a zone, replaced by the modern IANA ID, which is what we
should be using. Various aliases are omitted from lists, but can be
looked up via the alias table.
[ChangeLog][Third-Party Code] Updated timezone data from the Unicode
Common Locale Data Repository (CLDR) to v44.1 to match QLocale's data.
Change-Id: I8d89bef7370b93572a3dcf61f6713d4f21963e3d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Combine all into a single flexible apply method.
Also fixes a few issues with RGB colorspace on gray input. Blocking CMYK colorspace on Grayscale and ElementListProcessing RGB on grayscale out.
Fixes: QTBUG-125303
Change-Id: I3987010062fbb5aa708aeb1cc239f3ce9413e34f
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
That is printed at the top of the file and we've used it for the
copyright inside Qt, so just declare an alias.
[ChangeLog][uic] The Qt UI Compiler now accepts a <legal> XML tag to
indicate the copyright of the UI file and other legal terms of use. The
text of this tag will be emitted in the generated code. This tag is an
alias to <comment>.
Change-Id: If3345151ddf84c43a4f1fffd17d15ab77412e289
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
According to gnu.org[1]
> When a file is automatically generated from some other file in the
> distribution, it is useful for the automatic procedure to copy the
> copyright notice and permission notice of the file it is generated
> from, if possible.
This commit allows us to add copyright notices to the .qrc files
themselves and additionally have that be output into the generated .rcc
(of which we have a few committed to the repository)
[ChangeLog][rcc] The Qt Resource Compiler now accepts a <legal> XML tag
inside the main <RCC> entry, which can be used to document the copyright
of the resource file itself and other terms of use (even though the file
is probably created by a tool like Qt Creator's resource editor). The
text of this copyright will be emitted in the generated C++ or Python
source code.
[1] https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
Change-Id: If05cb740b64f42eba21efffd17d00417433f1ee9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Linux kernel version 5.8 added support for the stx_mnt_id field in the
struct statx because "Systemd is hacking around to get it and it's
trivial to add to statx, so...". This allows us to much more neatly
match the lines in /proc/self/mountinfo.
The same kernel version added STATX_ATTR_MOUNT_ROOT so we can tell if a
given path is the mount point of a filesystem. We don't have a need for
that information for now.
We need to retain fallback code for two reasons: first, the user may be
running with an old Linux kernel, in which case we won't get the
STATX_MNT_ID bit set in stx_mask. Second, we may have failed to open()
the path in question, because the user may not have the necessary
permissions.
There's still a race condition because the mount IDs can be reused
immediately after something is unmounted. There's a 64-bit unique mount
ID (available since v6.8) but it's not reported in /proc/self/mountinfo,
so we couldn't us it right now. We can with 6.8's statmount().
Pick-to: 6.7
Task-number: QTBUG-125721
Change-Id: If3345151ddf84c43a4f1fffd17d3f7dbce4ff16b
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Test this gesture with both mouse and touch.
Change-Id: I0285e7a17302361893c4b7ed0faf97c4f342814e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The RHI support and compositor in QPlatformBackingStore were
tied to the surface format of the top level window owning
the backing store.
This meant that inserting an RHI-enabled widget (QRhiWidget,
QOpenGLWidget, QQuickWidget, QWebEngineView) into the widget
hierarchy required recreating the top level window with a
matching surface format that could support the RHI composition.
It also meant that we could not have two RHI enabled widgets
with different surface format requirements (Metal and OpenGL
for example) in the same top level widget hierarchy.
The recreation of the window had various visual side effects,
such as temporarily switching out of full screen state, or the
widget rendering a frame of black, as well as more serious
problems such as not correctly restoring the window geometry.
In addition, if client code had pulled out the winId() of the
window, and did not invalidate these references on window
destruction via QEvent::WinIdChange or QEvent::PlatformSurface,
the client would reference stale window handles. Although
this is a programming error (QWidget::winId() specifically
mentions this requirement), we should avoid recreation if
we can.
We were already supporting flushing the backingstore to
individual native child widgets, but always did so via a
single RHI managed by the platform backingstore. By
expanding QPlatformBackingStore to keep one set of RHI
support and compositor per surface format, we can refine
the logic in QWidget and QWidgetRepaintManager to not
require recreating the top level. Native child widgets
are then flushed independently, including any RHI textures
and raster content that overlaps with the widget.
We still assume that a single RHI support and compositor
can be be used for multiple windows, as long as those
windows have the same surface format. In the future, if
needed, we can refine this to use one set per surface
format e.g.
Fixes: QTBUG-119221
Fixes: QTBUG-121181
Fixes: QTBUG-120096
Task-number: QTBUG-115652
Task-number: QTBUG-108344
Task-number: QTBUG-113557
Task-number: QTBUG-119309
Change-Id: I2635ed3d20c2fb76eab3b8130007dd656a0b93e5
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
We need to be able to have true popup windows in Qt Quick and Controls,
including handling the press-drag-release sequence to select one entry
from a menu or combobox. After the mouse press, a new window is created.
On some platforms (such as xcb), the new window gets window system grabs
of both keyboard and mouse (QApplicationPrivate::openPopup() calls
grabForPopup() and it actually works); while on others, the pre-existing
window continues to get the whole sequence of mouse events until the
release. In the latter case, Qt needs to forward events from the
original window to the popup. Until now, the list of popups was
QApplicationPrivate::popupWidgets.
Now we track the open popups as a list of QWindows rather than QWidgets,
in QGuiApplicationPrivate::popup_list, and add a set of static functions
to manage that list. Functions such as QApplication::activePopupWidget()
QApplicationPrivate::openPopup() and closePopup() are rewritten to make
requests to QGuiApplicationPrivate.
276943c8b7 made
QGuiApplicationPrivate::closeAllPopups() virtual. That is now reverted,
because we're putting QGuiApplication in charge of popup management
and trying to minimize widget-specific behavior. So far,
QApplicationPrivate::closePopup() is still overridden to take care
of focus changes.
So far, QtGui does not take care of closing popups when the user
clicks outside: the active popup window gets those events, and needs
to close itself if the click occurs outside. An attempt to move this
logic raised some issues with legacy widget test cases.
Using a touchscreen to press on QMenuBar and open a QMenu, drag to
a menu item and release, is temporarily broken for now. The plan is
to fix it in a subsequent patch.
Task-number: QTBUG-68080
Task-number: QTBUG-69777
Change-Id: I02b5034987b5ee8909917d305f414c8b0db9c7f5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
For backwards compatibility reasons, font files have multiple different
ways to specify vertical metrics (ascent, descent, etc.).
For OpenType, the main two are the usWin* and sTypo* metrics in the OS/2
font table. The usWin* metrics are typically used as the clipping bounds
of the font (so no character will ever draw outside these bounds). The
sTypo* metrics thus make it possible to specify a different set of
metrics for use in text layouts which is smaller than the clipping
bounds (or bigger), so that you can have fonts where some characters
overlap with preceding or subsequent lines.
However, GDI (and thus many applications) use usWin* also for line
spacing, which lead to the sTypo* metrics being untrustworthy in some
fonts and later to the introduction of the USE_TYPO_METRICS in the OS/2
table version 4. The idea of this flag is to tell the font system that
the sTypo* metrics can be trusted and should be preferred over the usWin*
metrics.
But the OpenType specification states that sTypo* metrics should *always*
be preferred and modern font systems such as FreeType and DirectWrite
will respect this. This in turn has lead to fonts where the
USE_TYPO_METRICS flag is untrustworthy instead, i.e. the sTypo* metrics
are preferable, but the USE_TYPO_METRICS has accidentally not been set.
Qt trusts the USE_TYPO_METRICS flag and uses the usWin* metrics whenever
this is unset. Since QFontMetricsF::height() (ascent+descent) in this
case includes the line gap metric, a lot of components have been written
to use it for size without adding any margins over the text. So changing
the default now would break a large amount of components, including the
ones in our own Windows style.
Most fonts should work correctly, by setting the USE_TYPO_METRICS flag
if the typo metrics are intended to be used. For those that do not, we
introduce a PreferTypoLineMetrics style strategy.
[ChangeLog][QtGui][Fonts] Added QFont::PreferTypoLineMetrics for using
the recommended line spacing metrics of the font, even if the font has
not explicitly set its USE_TYPO_METRICS flag.
Fixes: QTBUG-125585
Change-Id: Ib2f7df404fe719186d78733bda26da712f1ab85a
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
... to be in sync with QObject naming.
This amends b4c63b89df.
Change-Id: I25301f65aa880205d8c0cfd6f4bfa9fdba34a01c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Also write gray, CMYK and mAB RGB color space profiles.
Fixes: QTBUG-125302
Change-Id: Id3b3b64537b9c08f1d40b8243c228ad111d08289
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The test data is provided as float, so we must obey [conv.fpint]/1 when
converting from float to integer types. There are values in the rows
that are outside of the range of short and shorter integers, so just
check the range.
Fixes: QTBUG-125889
Pick-to: 6.7
Change-Id: If3345151ddf84c43a4f1fffd17d405ee0cd00d44
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The test passes locally, and if individual functions should fail, then
skip those.
Change-Id: Ib9123bacaff2a83c2bc378b37201fd1d75dfdb45
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We don't need the bodyName member, because it's the same as
originalBodyName, just encoded, and we can delay the encoding to
build() time.
This is not worse than the old code, since we anyway toString() the
QAnyStringView unconditionally.
So we don't need to visit the QASV and implement RFC2232 encoding for
all three view types, we can just use the QString version, after
toString().
This not only has the advantage of less code and not storing duplicate
data, but we now also encode u8"ä.txt" the same as "ä.txt"_L1 and
u"ä.txt", ie. using latin1, as required by Postel's Law, and not as
UTF-8, as the old code did.
Change-Id: If82a33a1cd09b859b3a4450a60083b1d3aedf7bc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Constructing and composing a QHttpMultipart contains some aspects that
are possible candidates for automating, such as setting the headers
manually for each included part. As a reference, when issuing a default
multipart with CURL, one does not need to manually set the headers.
Add the class QFormDataPartBuilder to simplify the construction of
QHttpPart objects.
Add the class QFormDataBuilder to simplify the construction of
QHttpMultiPart objects.
[ChangeLog][QtNetwork][QFormDataBuilder] New class to help constructing
multipart/form-data QHttpMultiParts.
Fixes: QTBUG-114647
Change-Id: Ie035dabc01a9818d65a67c239807b50001fd984a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Provide the new comparesEqual() helper function as an implementation of
(in)equality operators.
Use QT_DECLARE_EQUALITY_OPERATORS_HELPER macro instead of
Q_DECLARE_EQUALITY_COMPARABLE for the comparison between QPointer<T>
and QPointer<X> to avoid creating the reversed version of the
operators in C++17 mode.
Use new \compares command in the documentation to describe the
comparison operators provided by QPointer.
Task-number: QTBUG-120306
Change-Id: Iff24d3ef5c790de7f06ab825f853e06186fa1471
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This makes it possible for the stdCompatibility() test to cope with
the backend (based on the Windows Registry, which disagrees with MS's
ICU-based std::chrono::tzdb) successfully constructing a zone, by
finding a known alias, instead of failing because it doesn't know the
name. It may also be useful to client code when dealing with legacy
names.
Amended some existing tests to only expect what they now should and
added some tests specific to aliasMatches(). Also added some
explanative comments where it isn't needed.
Task-number: QTBUG-115158
Change-Id: I095bdbead78df339e29b29518d5010ef905fa8b2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Follow-up to commit 69555b364d, using
QTimeZone::isTimeZoneIdAvailable() instead of trying to construct an
ad-hoc test for known unknonwn zone IDs.
Reopens: QTBUG-102187
Fixes: QTBUG-102187
Change-Id: I36ff4f1dfbc4035d73df5b8fd68376c1bc9641e1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also rename the subdirs in the hiddenDirs_hiddenFiles test dir,
normalDirectory/normalDirectory/ is a bit confusing.
Make the test more deterministic by comparing lists of files/dirs
instead of just counts.
Change-Id: I12fdb5428bbef8382d4ee591792d167abcd216cf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
So far, the keys of icon engine plugins were only interpreted as the
suffix of icon files, loaded via QIcon(filename). However, an icon
engine could provide a lot more flexibility if it could implement an
entire theme.
Match the list of keys a plugin can register itself with also against
the current theme name. If a matching plugin is found, use that plugin
to create the icon engine. Store the factory from the plugin to avoid
costly lookups for each icon.
Extend the QIcon test case by adding a custom plugin that supports two
themes. Since the plugin and icon engine creation infrastructure
doesn't communicate which theme the plugin was created for, use
QIcon::themeName to record the current theme when the engine gets
created.
[ChangeLog][QtGui][QIconEnginePlugin] The keys registered by an
QIconEnginePlugin implementation are now also matched against the
current theme (system or user theme), allowing engine providers
to implement entire themes through a plugin.
Change-Id: I8a5e30ff8b5bb7c78b5204e82760e4328671e4c1
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This exercise found an inconsistency involving char16_t. Filed
QTBUG-125588 to keep track of this and decide how to deal with it.
Task-number: QTBUG-125588
Pick-to: 6.7 6.5
Change-Id: I259fecef34539e8841149570d7411d959b48d876
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Extending the fromCharacter() tests to check for the construction to
be noexcept and implicit turned up a few bugs:
The constructor from char32_t was simply not marked as noexcept, even
though all its operations were. So just mark it noexcept.
The constructor from QChar, otoh, was never called, (certainly not for
rvalues), because QString happens to be constructible from QChar (and
QLatin1Char and QChar::SpecialCharactor), so due to perfect
forwarding, the if_convertible_to<QString> ctor won, allocating a
QString.
This is a regression of Qt 6.5 compared to Qt 6.4.
To fix this, exclude arguments that convert to QChar from matching the
if_convertible_to<QString/QByteArray> ctors, taking care to not match
those arguments that are already compatible_char<>s.
This, in turn, creates a problem for implicit QASV construction from
QLatin1Char and QChar::SpecialCharacter, because now that we've
excluded them from the if_convertible_to<QString> ctor, calling the
existing QChar or QString non-template constructors for these types
would require two user-defined conversions (from said type to
QChar/QString and from QChar/QString to QAnyStringView). That works
for explicit construction, but we need implicit convertability.
So bring out the big guns once more and add a perfectly-forwarding
ctor for anything convertible to QChar. QChar itself is actually
already handled by compatible_char<>, so the old QChar non-template
ctor can go. The extra copy of the QChar argument will be optimized
away by the compiler.
[ChangeLog][QtCore][QAnyStringView] Fixed a regression where
constructing a QAnyStringView from a char-like type (QChar,
QLatin1Char, ...) would first construct a QString and only then
convert that to QAnyStringView.
Amends 812a0d3125.
This change is forward and backward BC and SC, but not
behavior-compatible: certain operations detectably change
noexcept'ness, and some arguments may now cause the resulting
QAnyStringView to have a different encoding (though I really tried
hard to avoid that).
Since it's a regression, I proposed to pick this to the affected
branches, 6.7 and 6.5 (6.6 is already closed at this point).
Pick-to: 6.7 6.5
Fixes: QTBUG-125735
Change-Id: I86f37df5d80bee36db27e529c017cb73995a6831
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Until now, QCryptographicHash had a big drawback over the underlying
C APIs: at least one extra memory allocation: Either you created a
QCryptographicHash object (allocates a Private), and enjoy noexcept
addData() and resultView(), or you used the static hash() function
(which creates a Private on the stack, so doesn't need to allocate
one), but then we needed to return in an owning container.
Enter QSpan and hashInto(), which allow the user to provide a buffer
into which to write, and therefore can be completely noexcept and
(apart from a missing optimization which, however, doesn't affect the
API) deliver near C-API efficiency.
We don't have QMutableByteArrayView, which would deal with the
different types of equivalent char types for us, so we overload for
QSpan<std::bytes>, QSpan<char> and QSpan<uchar>, which makes the
overload set accept roughly what QByteArrayView would accept, too.
Return by QByteArrayView because that has a richer API than QSpan,
which lacks (on purpose) string-ish API.
[ChangeLog][QtCore][QCryptographicHash] Added hashInto().
Task-number: QTBUG-125431
Change-Id: I80ecc7151d3418a36c4d5db6d22d0b82c869b19f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
These were not covered by the existing tests.
Pick-to: 6.7 6.5 6.2
Change-Id: I909ea3aa5b676904dc72ecf8ce32b73cca1b6af7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Create a temporary file instead of trying to use a file from source
directory because that's not available when test was installed via
packaging.
Task-number: QTBUG-118680
Change-Id: Ic152d68c79ac467c0d149cab04ab224c3b64099f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QTZ::displayName() returns an empty string if it doesn't know how to
localize a zone name. In this case, we can't expect it to match the
expected name, which depends on having relevant locale data available.
Task-number: QTBUG-115158
Change-Id: I1cd8c1469399502764c354bf24423298f106f23e
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
We were only handling the case where uri-list was a file.
This fixes a regression.
Also - add dragging url into the clipboard manual test
Pick-to: 6.7 6.7.1
Change-Id: Ifbd087ffd157463b6b903199e3ff22c2de1c4942
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This is meant to allow the buildsystem to add additional paths (for e.g.
QML imports) while still allowing the application to pick up the paths
where e.g. Qt's plugins are located – without having to query qtpaths or
the build system to locate them first, and to then also add them to
qt.conf.
QLibraryInfo::paths will return a list containing any values provided in
qt.conf, followed by the value that would have been provided if there
were no qt.conf file.
If no value is provided at all for a given key in qt.conf,
QLibraryInfo::path will behave as if no qt.conf file was provided,
instead of using LocationInfo::defaultValue.
For now, this is considered to be internal only, and won't be
documented.
Change-Id: Ic74c66b5cbde605b43336cd88c3f909999381f46
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add missing checks for integral overloads uint, short and ushort and
character overloads char and char16_t (the latter being a reproducer
for QTBUG-125588).
Pick-to: 6.7 6.5 6.2
Task-number: QTBUG-125588
Change-Id: I479e4c8c3cd86c3f85ab3c9d44b79158b0a48476
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
setFloating() called on the 2nd last dock widget in a floating tab
didn't cause reparenting to the main window. The dock widget remained
parented to a QDockWidgetGroupWindow, while no longer being part of
floating tabs. The QDockWidgetGroupWindow would therefore have only
one tab, which is an inconsistent state and causes crashes.
Factor out the implementation of setFloating() to a new
QDockWidgetPrivate::setFloating(). Reparent to the main window, if
the dock widget is part of floating tabs.
Add test functionality in tst_QDockWidget::setFloating().
Turn createFloatingTabs() into a macro, in order to QSKIP() in the test
function's scope.
Fixes: QTBUG-122394
Pick-to: 6.7 6.5
Change-Id: I3719785f310b131446cdea908f09b7195c992b3e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Ahmad Samir
Volker Hilsheimer
Thiago Macieira
Mårten Nordheim
Rym Bouabid
Ivan Solovev
Marc Mutz
Tor Arne Vestbø
Christian Ehrlicher
Jari Helaakoski
Oliver Wolff
Edward Welbourne
Allan Sandfeld Jensen
Shawn Rutledge
Eskil Abrahamsen Blomfeldt
Mate Barany
Robert Löhning
Ari Parkkila
Lorn Potter
Fabian Kosmale
Axel Spoerl