Add Qt::begin/endPropertyUpdateGroup() methods.
These methods will group a set of property updates together and delay
bindings evaluations or change notifications until the end of the update
group.
In cases where many properties get updated, this can avoid duplicated
recalculations and change notifications.
Change-Id: Ia78ae1d46abc6b7e5da5023442e081cb5c5ae67b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When a property value changes, first update all dependent bindings to
their new value. Only once that is done send out all the notifications
and changed signals.
This way, if a property depends on multiple other properties, which all
get changed, there will only be one notification; and (potentially
invalid) intermediate values will not be observed.
Fixes: QTBUG-89844
Change-Id: I086077934aee6dc940705f08a87bf8448708881f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
While we do not support cross-thread bindings, reading of properties
from a different thread when no bindings are involved must continue to
work.
However the check whether bindings are involved used the QBindingStatus
in the QObjectPrivate. That one contains the wrong value when the
QObject is accessed from a different thread than the one it has affinity
with. This patch reads from the thread_local directly instead to
sidetstep the issue.
Change-Id: I8ce2092f35e210566934e2439beb5d48fd8cf226
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Too much of the existing code in Qt requires eager evaluation without
large scale modifications. Combined with the fact that supporting both
eager and lazy evaluation has a high maintenance burden, keeping lazy
evaluation, at least in its current state, is not worth it.
This does not diminish other benefits of the new property system, which
include
- a C++ API to setup and modify bindings and
- faster execution compared to QML's existing bindings and the ability
to use them without having a QML engine.
We do no longer benefit from doing less work thanks to laziness. A later
commit will introduce grouping support to recapture some of this
benefit.
[ChangeLog][Import Behavior Change][QProperty] QProperty uses always
eager evaluation now when a dependency in a binding changes.
Change-Id: I34694fd5c7bcb1d31a0052d2e3da8b68d016671b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Remove the MinGW-related hack that was introduced in
ec31953007. It doesn't seem to be needed
anymore with recent MinGW versions and prevents using a system jpeglib
that disagrees in its jboolean declaration with our bundled jpeglib.
Fixes: QTBUG-88093
Change-Id: Ic6eb03b4b395fe3e8dcedf52489e8642289fc98e
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In Qt 6, QMultiHash does not iherit QHash
Pick-to: 6.1 6.0
Change-Id: Iaad8768d681a9aad2bb1f80fd87904f0dd9683d4
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
CMake 3.18 introduced the file(ARCHIVE_CREATE) API that we use with
COMPRESSION Zstd for compressing corelib's mimedatabase.
It's possible to build CMake without proper zstd support, and we have
encountered such builds in the wild where the file(ARCHIVE_CREATE) call
crashes.
Add a configure test to determine whether CMake properly supports the
Zstd compression method.
Fixes: QTBUG-89108
Change-Id: I37e389c878845162b6f18457984d4f73a265b604
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
GCC 10 in C++20 mode will still try to use
std::indirectly_readable_traits on QList iterators, and since it
does not have the fixes for LWG 3346 / 3541, it will fail to build:
/usr/include/c++/10/bits/iterator_concepts.h: In substitution of ‘template<class _Tp> using __iter_value_t = typename std::__detail::__iter_traits_impl<_Tp, std::indirectly_readable_traits<_Iter> >::type::value_type [with _Tp = QList<std::pair<int, int> >::const_iterator]’:
/usr/include/c++/10/bits/iterator_concepts.h:248:11: required by substitution of ‘template<class _Tp> using iter_value_t = std::__detail::__iter_value_t<typename std::remove_cv<typename std::remove_reference<_Tp>::type>::type> [with _Tp = QList<std::pair<int, int> >::const_iterator]’
/usr/include/c++/10/bits/iterator_concepts.h:468:11: required from ‘class std::reverse_iterator<QList<std::pair<int, int> >::const_iterator>’
../src/corelib/itemmodels/qsortfilterproxymodel.cpp:669:43: required from here
/usr/include/c++/10/bits/iterator_concepts.h:243:13: error: ambiguous template instantiation for ‘struct std::indirectly_readable_traits<QList<std::pair<int, int> >::const_iterator>’
243 | using __iter_value_t = typename
| ^~~~~~~~~~~~~~
/usr/include/c++/10/bits/iterator_concepts.h:231:12: note: candidates are: ‘template<class _Tp> requires requires{typename _Tp::value_type;} struct std::indirectly_readable_traits<_Iter> [with _Tp = QList<std::pair<int, int> >::const_iterator]’
231 | struct indirectly_readable_traits<_Tp>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/10/bits/iterator_concepts.h:236:12: note: ‘template<class _Tp> requires requires{typename _Tp::element_type;} struct std::indirectly_readable_traits<_Iter> [with _Tp = QList<std::pair<int, int> >::const_iterator]’
236 | struct indirectly_readable_traits<_Tp>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So hide element_type as well.
The CI didn't catch this because the CI doesn't build in C++20 mode.
Amends 595b4e1a9b.
Change-Id: I5c8e47d693ca584571cd89f856d08ba249dd05ab
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Currently we support:
QString s = QString::fromUtf(u8"foo", 3);
But we don't support
QString s = QString::fromUtf8(u8"foo");
QString s(u8"foo");
There's no reason not to have these two functions. Guess what,
we've actually got code _in Qt_ that tries to build a QString out of
a char8_t; that code stops compiling under C++20 (which is supported,
but not CI-tested at the moment, it seems).
Re-add the missing constructor and fromUtf8 overloads.
[ChangeLog][QtCore][QString] Added a constructor and a fromUtf8()
overload taking a `const char8_t *` argument.
Task-number: QTQAINFRA-4117
Task-number: QTQAINFRA-4242
Change-Id: I1f0ae658b3490b9e092941cabcc7fb8fc4c51aa3
Pick-to: 6.1.0 6.1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If one "accidentally" uses a release build of the unicode tool,
the asserts within it won't fire. Enable them in all cases.
Change-Id: I9d63641dc6d6d2e5805b61b36f8c28e624b25e12
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Prior code was naively assuming the character after a high surrogate
would necessarily be a low surrogate, which is buggy.
Fixes oss-fuzz issue 29718.
Pick-to: 6.0 6.1 5.15
Change-Id: I10f023c4b5024a0d76fea0a3672001063591ec6d
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We need the metatypes for anything directly or indirectly exposed to
QML. Switching this on has no runtime overhead. For interface libraries
we cannot generate any metatypes, though.
Change-Id: I7b7f85bb4e16c28d00383c5c88b0f1c172c8d193
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It is slow and will use too much memory.
Pick-to: 6.1 6.1.0 6.0 5.15
Fixes: QTBUG-91889
Change-Id: I45c5e6038357c87bbb85b1ace17ef39a2a814ea0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This patch adds helper methods to test bindable properties in the QTest
lib. These methods can be useful in many Qt modules, so we decided to
have them in qtbase.
For now they are in the private header, because we are not sure that
they can be useful for the end users.
Task-number: QTBUG-89874
Change-Id: I6738728df1bcd895758008ef2ade0d3693802c3e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Because take() is deprecated, and these pointers are meant to leave the
scope in some branches.
Pick-to: 6.1
Change-Id: I5432d91a28f4c5c8c17fadf7ce3bcd41716e216a
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Presumably the code at some point would do a
QByteArray::fromRawData-style thing. But now it doesn't do that so
the current code was a bit strange. It would map the content of the file
to memory only to then copy the content into a QByteArray. Then it
reparents the file to the QBuffer, keeping it alive even if its not
needed.
Fixes: QTBUG-92838
Pick-to: 6.1 6.0 5.15
Change-Id: I88f8cd1b64e0fd13d08b5cc4df44661e216da340
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It was originally marked \obsolete without any comment on what was to
be used to replace it, or deprecation markings in the declaration, so
it got missed at 6.0. More recently it's been deprecated in favor of a
territory-based name; but actually it was obsoleted by (iterating the
territory() of each return from) matchingLocales() in Qt 4.8.
So back out of adding territoriesForLanguage to replace it and,
instead, mark it as deprecated in the declaration, in favor of
matchingLocales(). Also rewrite the implementation to be exactly that
replacement. Rewrote the one example using it.
Fixes: QTBUG-92484
Change-Id: Iedaf30378446dd9adac5128b7ee5fee48aab1636
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Follow up on some comments saying "TODO Use QTimeZone when available"
in converting times, outside the range supported by the system's
time_t functions, between local or zone time and UTC. Since this
required two formerly static functions in qdatetime.cpp to access
QTimeZone's d-ptr, turn those into methods of QTZ's friend QDTPrivate.
Change-Id: I27fe03d8eff9f4e98661263b1a1d4d830f4e7459
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
At least some modern 64-bit systems have widened time_t to 64 bits
fixing the "Unix time" problem. (This is even the default on MS-Win,
although the system functions artificially limit the accepted range to
1970 through 3000.) Even the 32-bit range extends into January 2038
but the code was artificially cutting this off at the end of 2037.
This is a preparation for using the same also all the way back to the
start of time_t.
In the process, simplify and tidy up the logic of the existing code,
update the docs (this includes correcting some misinformation) and
revise some tests.
Fixes: QTBUG-73225
Change-Id: Ib8001b5a982386c747eda3dea2b5a26eedd499ad
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the backends run into an error in computing the offset, they return
INT_MIN; but they are valled via the front-end, which returns zero
when the zone is invalid. So treat INT_MIN returns from the backend
the same as the case of being invalid.
Change-Id: Ic3c4dfe964dbfba4030c770213eca8a63e84736d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For QProcess, there is no point in suppressing recursive
QWPR::readyRead() emission, as the former manages this logic itself. On
top of that, the non-recursive nature of QWPR::readyRead() indirectly
disallowed reading from the channels inside
QProcess::waitForReadyRead(), if that is called from a slot connected
to QProcess::readyRead().
QWPW had two signals, one allowing recursion and one not.
This commit allows recursion of QWPR::readyRead() and
QWPW::bytesWritten(), and moves recursion suppression to the higher-
level classes. This makes the code more uniform and efficient, at the
cost of a few duplicated lines.
Change-Id: Ib20017fff4d92403d0bf2335f1622de4aa1ddcef
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
pro2cmake did not take into account the
QT -= qt
bit of the .pro files.
Fixes: QTBUG-91676
Change-Id: If1373ee966312e4246490bd7389d75be9fa739cb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Homebrew introduced a new default prefix for Apple Silicon machines,
so that both arm64 and x86_64 packages can be co-installed on a single
system.
The intel packages are installed into /usr/local and the arm64
packages are installed into /opt/homebrew.
For Qt building purposes, we don't want to find packages in any of
homebrew's prefixes unless explicitly requested by the user
Currently our arm64 macOS CI config does pick up system libs under new
prefix.
Remove the new path from the system prefixes.
Amends f3c7d22dd0
Task-number: QTBUG-85447
Change-Id: I381d31c95bcdab26147a331444ba40c7af9d0a95
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
So that the correct version is generated in top-level builds.
Change-Id: I360370815ce178564cc79157dc61d70adfd4f947
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Documented the fall-back process by which QLocale selects an actual
locale based on what it is asked for. The prior documentation was
wrong.
In the process, removed some out-of-date claims about QString's
toInt() and toDouble() caring about the default locale; and caught a
few more cases (in \internal docs) of country -> territory.
Fixes: QTBUG-90962
Change-Id: I5e7cfa66443c9335a71fb2048c3f2ebf7af64573
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously the (language, territory) constructor had optional
territory; however, the (language, script, territory) one required all
three. Making the latter's script and territory optional, while
requiring the former to pass territory, makes it possible to construct
with (language), with (language, territory), with (language, script)
or with (language, script, territory), without (overt) use of AnyScrit
or AnyTerritory.
Change-Id: Iaf6e46c473042d886eee7068515f9e41a704c2e7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The use of "Country" is misleading as some entries in the enumeration
are not countries (eg, HongKong), for all that most are. The Unicode
Consortium's Common Locale Data Repository (CLDR, from which QLocale's
data is taken) calls these territories, so introduce territory-based
names and prepare to deprecate the country-based ones in due course.
[ChangeLog][QtCore][QLocale] QLocale now has Territory as an alias for
its Country enumeration, and associated territory-based names to match
its country-named methods, to better match the usage in relevant
standards. The country-based names shall in due course be deprecated
in favor of the territory-based names.
Fixes: QTBUG-91686
Change-Id: Ia1ae1ad7323867016186fb775c9600cd5113aa42
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use PROJECT_VERSION instead of CMAKE_PROJECT_VERSION when setting the
version of a qml module, which extracts the version of the latest
project() call rather than the top-level one.
Using CMAKE_PROJECT_VERSION caused issues in top-level builds where
the qtdeclarative version is 6.2, but the top-level project version is
still 6.1 and hasn't been updated to 6.2, causing qml module import
errors.
This was probably an oversight during initial implementation of qml
support in pro2cmake.
So projects that define qml modules should be adapted accordingly.
Amends cce8ada814
Amends 28fff4a551
Pick-to: 6.1 6.0
Task-number: QTBUG-92861
Change-Id: I494784694e997501a5bc4fd0c0eac458ddc248aa
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
CMake makes possible to specify a target in the target_link_library
call even if the target is not declared yet. This adds flexibility to
the target declaration arrangement. For the Qt modules we have to
restrict freedom, because of the .prl files generating. If the Qt
module depends on another Qt module, the dependecy must be declared
before the module finalizing step, otherwise this will cause invalid
records in the module .prl file.
TODO: The dependency order issue could be solved by using conditional
genex's when generating step1 .prl file. But we ask developers to
depend on Qt module targets that have been defined before their usage.
Fixes: QTBUG-89467
Change-Id: I12ce1000048fd4a2f3334f17720c8df1c680ca20
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
With this enumeration value, users can get the width of
the current font TAB character more conveniently
In addition, added some documentation about where
users may use this enumeration.
Fixes: QTBUG-92205
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: I9794b7553e9299e351f9182de02866d07a1393fc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Looks like these ones have been forgotten in the Qt 5 -> 6 upgrade
to qsizetype. Change them to return qsizetype as well,
and fix the docs. Being entirely inline, non-exported classes, we
should be able to get away with it without affecting binary
compatibility. Moreover, there's no reason for keeping them
deprecated.
Requires some minor adjustments, just like the ones done for
size()'s changes.
[ChangeLog][QtCore][QStringView] The length() function
now returns `qsizetype`, not `int`, for consistency with the
other string and container classes in Qt. Following this
change, it has been un-deprecated.
[ChangeLog][QtCore][QAnyStringView] The length() function
now returns `qsizetype`, not `int`, for consistency with the
other string and container classes in Qt. Following this
change, it has been un-deprecated.
[ChangeLog][QtCore][QUtf8StringView] The length() function
now returns `qsizetype`, not `int`, for consistency with the
other string and container classes in Qt. Following this
change, it has been un-deprecated.
[ChangeLog][QtCore][QByteArrayView] The length() function
now returns `qsizetype`, not `int`, for consistency with the
other string and container classes in Qt. Following this
change, it has been un-deprecated.
Fixes: QTBUG-92496
Change-Id: Ie0f4939d1083884e95d4725f891b6c6764532cb8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The find script checked for UIKIT which is set during a Qt build
in QtPlaformSupport.cmake but is not set when building a user project.
This casused the find script to skip the iOS specific code that
passed the -framework OpenGLES linker flag.
This broke SDK switching in Xcode.
Check the IOS variable instead which is set by CMake for all projects
that pass -DCMAKE_SYSTEM_NAME=iOS.
Pick-to: 6.1
Change-Id: I9bd088f317917544ccfeff61fc4ff90f18f0f3d8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
