Static Qt plugins should not be included in the list of libraries of
a prl file. They end up being there due to our circular dependency
trick where the plugins depend on the module they belong
to.
This in turn causes the giant static plugin generator expressions to
be processed in qt_collect_libs(), and the generated prl file ends up
having target names like Qt6::QJpegPlugin which are obviously not
linker flags.
To eliminate the static plugins from prl files, add an additional
dummy boolean generator expression '$<BOOL:QT_IS_PLUGIN_GENEX>'
that always evaluates to true. We can string match on this expression
in qt_collect_libs, and thus remove the whole static plugin genex
entry.
This should fix linking of apps with qmake that use a CMake-built
static Qt.
Task-number: QTBUG-85865
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: I949dc5edb10d94c4ab84ed430af7c164d8efaaa6
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
In particular switching the SUBPIXELS macro with FRACT makes the logic
valid for all 24dot8 fixed point values.
Change-Id: I4e58df94f8cf3c557f670c5d3088942e9b8efa6d
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
mkspecs/features/qt.prf adds a dependency on the system threading
library if the Qt Core thread feature is enabled. Because qt.prf is
loaded by any public or internal Qt project, it's essentially a public
dependency for any Qt consumer.
To mimic that in CMake, we check if the thread feature is enabled, and
and set the Threads::Threads library as a dependency of Qt6::Platform,
which is a public target used by all Qt modules and plugins and Qt
consumers.
We also need to create a Qt6Dependencies.cmake file so we
find_package(Threads) every time find_package(Qt6) is called.
For the .prl files to be usable, we have to filter out some
CMake implementation specific directory separator tokens
'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call
target_link_libraries() with a target created in a different scope
(I think).
As a result of this change, we shouldn't have to hardcode
Threads::Threads in other projects, because it's now a global public
dependency.
Task-number: QTBUG-85801
Task-number: QTBUG-85877
Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Also remove duplication by centralizing the main code for
erase(), and implement erase(pos) in terms of erase(first, last).
Change-Id: Ie0272ebac92fd7da48c31f9d68e69a2faa583bbc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Receiving an rvalue still requires to check whether the parameter
is detached, otherwise we can't steal its backing std::map.
Change-Id: Ie88dbf39fd777112ad7bb20a46d5c2d65be8eb3d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... and QMultiMap as std::multimap.
Just use the implementation from the STL; we can't really claim that
our code is much better than STL's, or does things any differently
(de facto they're both red-black trees).
Decouple QMultiMap from QMap, by making it NOT inherit from
QMap any longer. This completes the deprecation started in 5.15:
QMap now does not store duplicated keys any more.
Something to establish is where to put the
QExplictlySharedDataPointer replcement that is in there as an
ad-hoc solution. There's a number of patches in-flight by Marc
that try to introduce the same (or very similar) functionality.
Miscellanea changes to the Q(Multi)Map code itself:
* consistently use size_type instead of int;
* pass iterators by value;
* drop QT_STRICT_ITERATORS;
* iterators implictly convert to const_iterators, and APIs
take const_iterators;
* iterators are just bidirectional and not random access;
* added noexcept where it makes sense;
* "inline" dropped (churn);
* qMapLessThanKey dropped (undocumented, 0 hits in Qt, 1 hit in KDE);
* operator== on Q(Multi)Map requires operator== on the key type
(we're checking for equality, not equivalence!).
Very few breakages occur in qtbase.
[ChangeLog][Potentially Source-Incompatible Changes] QMap does not
support multiple equivalent keys any more. Any related functionality
has been removed from QMap, following the deprecation that happened
in Qt 5.15. Use QMultiMap for this use case.
[ChangeLog][Potentially Source-Incompatible Changes] QMap and
QMultiMap iterators random-access API have been removed. Note that
the iterators have always been just bidirectional; moving
an iterator by N positions can still be achieved using std::next
or std::advance, at the same cost as before (O(N)).
[ChangeLog][Potentially Source-Incompatible Changes] QMultiMap does
not inherit from QMap any more. Amongst other things, this means
that iterators on a QMultiMap now belong to the QMultiMap class
(and not to the QMap class); new Java iterators have been added.
Change-Id: I5a0fe9b020f92c21b37065a1defff783b5d2b7a9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
biHeight may be int_min, in which case qAbs<int>() will not work.
Fixes: oss-fuzz-22997
Pick-to: 5.15 5.12
Change-Id: Ic07d5aa0b4e4f2b6395e1a12d742e31b5282fdfc
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The include directory in Qt's build directory is always named
"include", no matter what the value of INSTALL_INCLUDEDIR is. The main
reason is that the name "include" is hard-coded in syncqt.
The INSTALL_INCLUDEDIR variable must only affect the installation
location of headers.
Fixes: QTBUG-85893
Change-Id: I5367bc589cba129eb41817e2b58d470f730bb5ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the logging category qt.pointer.grab, which generalizes the
qt.quick.pointer.grab category in Qt 5 (and is almost always needed
for troubleshooting Qt Quick pointer-handling bugs).
Change-Id: I10b4f43aa60e8717d92ac43384d8fdeefd41d836
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
In preparation for the QMap/QMultiMap split. The previous code
had a workaround for storing multimaps, because the CF classes
actually don't support it: build a dictionary from one key
to a _list_ of values. Stop doing that.
In principle, if QMultiMap support does get added to QVariant
(which it probably should), then a similar workaround could be
readded for QMultiMap support.
[ChangeLog][Important Behavior Changes][QSettings] On Apple platforms,
when using the native format, QSettings is no longer able to handle
QVariantMap values which are actually multimaps. Since the native storage
does not actually support multimaps, QSettings used to flatten and
unflatten the maps. However, with QMap being changed to no longer
allow for equivalent keys, flattening when writing does not make
sense any more (there cannot be equivalent keys, because QMap in Qt 6
is a single-key map). Reading existing settings is supported by having
a key in the map mapping to a QVariantList of values.
Support for QMultiMap may be added back to QVariant and QSettings in a
future version of Qt.
Change-Id: Iaa9535100fe5ef55693f22a2068454a84180b4a6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QFontDatabase is a singleton and all instances would share
a single, mutex-protected global data pointer. But some functions
were implemented as non-static functions. This caused a lot
of code on the form
QFontDatabase().families(...)
since there was no static access. Other functions were implemented
as static.
To consolidate, we make all functions static. This should be
source-compatible, but not binary compatible.
[ChangeLog][QtGui][Fonts] Some functions in QFontDatabase were in
principle static, but previously not implemented as such. All
member functions have now been made static, so that constructing
objects of QFontDatabase is no longer necessary to access certain
functionality.
Fixes: QTBUG-83284
Change-Id: Ifd8c15016281c71f631b53387402c942cd9c43f6
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Discard the color space and return the selected RGB/CMYK
color components, without any color space conversion.
This enables predictable color handling as long as you
stay on a single display. All color triplets are display
RGB: drawing the QColor returned by getColor() will
reproduce the selected color on-screen.
(Predictable color across multiple displays require
color management, which is out of scope here).
Fixes: QTBUG-84124
Pick-to: 5.15
Change-Id: I43d8dc15d07635fabdd0662c84f7c0b5ac40b7ab
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QQuickPointerEvent had them, so despite how trivial they look,
it's very convenient to keep using them in QQuickWindow rather than
duplicating these kinds of checks in various places, and for multiple
event types too.
Change-Id: I32ad8110fd2361e69de50a679ddbdb2a2db7ecee
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
There was no good reason for QEventPoint::pressTimestamp() to be
missing. The case for QEventPoint::timestamp() is a bit dubious
because it's redundant with QInputEvent::timestamp(); but for now,
we keep m_timestamp, in anticipation that Qt Quick may need to keep
copies of eventpoints between events, thus they need to avoid depending
on their shorter-lived parent events too much.
Change-Id: Iec38acfdfaa2afb3dc77d5cd1b95baa8d301c0fd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The build breaks by disabling ASan in this function because it also
removes its ability to emit SSE2 code. That's clearly broken because all
x86_64 can use SSE2. So this adds #warnings so people are told how to
choose their solution.
Clang doesn't currently define __SANITIZE_ADDRESS__ but I added a
conditional just in case some future version does.
Fixes: QTBUG-84856
Pick-to: 5.15
Change-Id: I552d244076a447ab92d7fffd1617875fdd8dbe62
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
This allows us to skip the surrogate pair decoding too, since it can't
match anyway.
Change-Id: Ied637aece2a7427b8a2dfffd16118183e5d76794
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The implementation was broken. The "high" in PUNPCKHBW's "unpack high
data" means the high 64-bit of the 128-bit, not the high byte of a 16-
bit word. This never worked. It always passed for me because I don't
build non-SSE4.2 code (too old, no longer relevant).
So just use the working version of simdTestMask.
Pick-to: 5.15 5.12
Change-Id: I35a1b4d0a19a43149daefffd16284542f0de3fa3
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Even added an internal char8_t type if the compiler doesn't have one.
Change-Id: Ied637aece2a7427b8a2dfffd1611813c345d10ec
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The problem was that QtCore exported those classes deriving from
containers, which caused applications to try and import those same
functions from QtCore, depending on whether they saw the #include or
not.
Now we don't need the hack anymore.
Change-Id: I0a103569c81b4711a649fffd14ec9282454a1fdc
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Changes are not too big for now. Just replaces use of the previous
calls to the zlib decompression function. And initialize
QDecompressHelper when we know the content-encoding.
Task-number: QTBUG-83269
Change-Id: I41358feaef2e7ac5f48f14e3f95ec094e0c110b7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Some servers have an upper limit on how many times a nonce can be
reused. Because the nc was not being reset the server would get a
high nc and would close the connection.
Change-Id: I71d5a316f79777a45c7323d93e28b3845aefcfad
Original-patch-by: Benjamin Reikowski
Pick-to: 5.15
Fixes: QTBUG-85729
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
By default, mobile browsers create a (layout) viewport
much wider than the visual viewport in order to be
compatible with web pages created with desktop browsers
in mind.
This means that the default view is zoomed out. This
zoom is not reflected in window.devicePixelRatio, and
Qt ends up setting the canvas render size to be larger
than actually needed.
The window.visualViewport.scale property reflects this
“mobile” zoom level: add it as a devicePixelRatio factor.
(The value will be less than 1 when zoomed out). User
pinch-to-zoom may change the zoom level and resize
the visual viewport; install a resize handler as well.
For now we limit the devicePixelRatio value in order
to avoid creating gigantic backing store images - this
is something we can revisit later on.
Pick-to: 5.15
Task-number: QTBUG-85662
Change-Id: I96db6121fe17a6c213216e04e4724efc93a9b66a
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This is a good default, and also works around a couple
of current bugs in the Qt implementation. (Applications
can change the default values in the .html file as
needed.)
Change body height to 100% of the visual viewport (“100vh”)
to make the html body cover 100% of the viewport after
landscape -> portrait transitions on iOS.
Pick-to: 5.15
Task-number: QTBUG-85536
Task-number: QTBUG-85662
Change-Id: Iced1aee03940361c96f1fe3c104f3e6eb983cb90
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Install XSettings property change callback on the “Xft/DPI”
property. Update QxcbVirtualDesktop::m_forcedDpi and QScreen
logicalDPI on change.
Pick-to: 5.15
Change-Id: I578ebe9017fee58acd7a5c432cbd614fd35f2f55
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
After enabling Qt::AA_UseHighDpiPixmaps, QIcon::pixmap()
now returns pixmaps larger than the requested size on
devicePixelRatio > 1 screens.
Adapt tests to account for this changed behavior.
Skip tests where it’s unclear what the the expected
behavior is, or where the test logic does not apply
to dpr > 1.
This gives a clearer indication of where we are
(39 passed, 0 failed, 9 skipped), and enables using
the qicon test to catch regressions also when running
at dpr > 1.
Remove the "lowdpi" testcase flags from the qmake and
cmake project files.
Change-Id: Ia7ce722ae356fc496a91b54e9f5d590d13b9df62
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Old data was held in buffers which caused OpenGL paint engine to
re-render previous shape again with current settings if the current path
was completely clipped.
Pick-to: 5.15
Fixes: QTBUG-35513
Change-Id: I0cd448e0b18d199af11e82d79b1ab72d0f89c79e
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The logic is a bit involved in qmake.
The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies
to qt modules, qt plugins, qml plugins, qt helper libs, winmain and
qt_apps, qt_tools, but NOT tests (which is important because the tests
on Windows MinGW fail to build without the GNU extensions).
Then default_post.prf checks for the strict_c++ value and either uses
the strict or non-strict C++ standard flags. default_post.prf is
loaded for all qmake projects, not just the Qt internal ones.
Now CMake doesn't provide a transitive based option to disable C++
GNU extensions with a mechanism similar to target_compile_features.
It only provides the CXX_EXTENSIONS property and it's associated
CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a
directory scope, because that is too coarse grained.
So we rely on setting the property via a function in every relevant
qt_add_<target> function.
Now the naming of the function is weird.
We name the function as qt_internal_<...>, because it's not meant to be
used by Qt users.
We prepend an underscore to the name because we need to place it in
Qt6CoreMacros, so that the function can be called by
qt_add_qml_module which IS a public function.
That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 +
CMake we decided to make qt_add_qml_module() as public API.
Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Eliminate some needless parentheses, tidy up some spacing and
indentation and split some long lines. Change first += after
declaration to initializer.
Change-Id: I05ff2a6337b7ed14e0a2dc9c03fc784c92b63515
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Adding these method definitions because QtApplication might fail
to find them.
Change 80f7494e8a added few exceptions
printStackTace(), the line
src/android/java/src/org/qtproject/qt5/android/bindings/QtApplication.java#106
prints error of java.lang.NoSuchMethodException for these methods.
Pick-to: 5.15
Change-Id: I63b1f0d3abd5a7fe7d9e87bbff252c437300722f
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
To support streaming decompression in QNAM.
Will also be used to refactor existing decompression code in QNAM.
Task-number: QTBUG-83269
Change-Id: Iecf3e359734163f15686c949f75d41fa4794a00e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the new event APIs and split the single mouse event into
three separate events (move, press, release). QNX events only
give us current state, deduce the pressed and released buttons
by comparing to the previous state.
Change-Id: I9e647922679ddb792b10cb5e6ceee7ede4878444
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
Avoids the conversion from UTF-8 for uses that are not dumping a string.
Mass conversion of Qt sources left for future opportunity.
Fixes: QTBUG-85811
Change-Id: I4ca4a35b687b46c39030fffd1626ae6c3294cacf
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The operators were declared as friend function templates (so, free
functions in the Qt namespace). Unfortunately, the template argument
of the operators was also defaulted -- causing MSVC trying to
instantiate those functions at all times, causing interesting
recursive template instantiation errors (C2968). It's extremely
likely that we're facing a MSVC bug, but work around it by not
defaulting the template argument. This in turn requires to move
the function definition outside QList's definition, otherwise
an extern template definition (like the ones we have for QList<QPoint>)
would cause a template redefinition error...
Change-Id: If03477ac1fa0a72aa252bb9e08e2a19c2b517b1b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
After adding QByteArrayView overloads of QByteArray methods that used
to take char*, the way of determining the length of passed fixed-sized
array data has changed, due to the QByteArraiyView's optimization to deduce
the length at compile time for arrays. Document the behavior and add a
changelog item.
[ChangeLog][QtCore][QByteArray] When passing fixed size C arrays to
QByteArray methods, the length of the data on which the method will operate
is determined by array size, and not by scanning for the first '\0'
terminator, as it was in Qt 5.
Task-number: QTBUG-85815
Change-Id: I11cba17d428791e06c9bd4c7a727b7bd6b6aec3c
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QByteArrayView's comparison operators are declared in the global
namespace, which can collide with the ones declared for other types that
are implicitly convertible to QByteArrayView (see the example attached to
the bugreport). Changing them to be hidden friends will make them visible
only when at least one of the operands is a QByteArrayView, so the
ambiguity will be avoided.
Fixes: QTBUG-85880
Change-Id: Ic3582269d9bda9a2105336ef0f044ea619af37ba
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We have several classes inheriting QObject (directly or not) and disabling
copy (thus non-movable implicitly). Let's make them non-movable explicitly
now.
Change-Id: I509a066e9977480b30842afef26319b8afec6001
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Windows shared library prl files should not have a
QMAKE_PRL_LIBS section. Such information is not useful because it's
not used by the linker as per 523c7e3fd5
Amends 46d7abc9172f82756ccd3641a314dcc066353c3f
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: Ic40491a568f72c507a16322f6f0c61f98d3a5913
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Qt6 makes sizes qsizetype; and one of these was already sizeof()-sized.
While qsizetype might not be ssize_t, it's at least no bigger, so we
can safely use its format specifier, with a suitable cast.
Change-Id: I433f654f6b139d74b4d5358b804b44ab1f0ada15
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Removed three warnings, rather than fixing them, as Konstantin Ritt
tells me they've been redundant since Unicode 6 or so.
Change-Id: I4507e852bceb08a0252c77a8b383aceac212aad9
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
