The ranged constructor for QList has an optimization when the
iterators are QList's own iterators. In that case, it uses a
"contiguous append" shortcut by converting the iterators to pointers.
Avoid that conversion by extracting the pointers from the iterators.
Note that this is an optimization for C++17 only; in C++20
appendIteratorRange will deal with this case as well. Leave a note.
Change-Id: I761c36ff500dee95b4ae1b0a4479d22db0c8e3de
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Do not rely on implicit pointer->QList::(const_)iterator conversions.
Amend QList's own code so to avoid them.
Change-Id: Ia3e7a83631943e636831217cdad28b73c98c1dc7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The use of ndk.dir in local.properties is deprecated in favor of
android.ndkVersion in build.gradle, and will be totatlly removed in
the future, so we need to adapt to that.
Fixes: QTBUG-91391
Pick-to: 6.2
Change-Id: I54c57113a759d43c3685c9cdf2b9dcc5c948c0fd
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
QAbstractScrollAreaPrivate::layoutChildren() positions the viewport, but
did not take the overshoot from scrolling with a scroller into account.
If the scroll area was resized during a scroll, then this resulted in the
roll back overcompensating for the overshoot, placing the viewport outside
the visible area.
Fix this by taking the overshoot into account when positioning the
viewport.
Add a test case. We have to use QWindow-based mouse event simulation, as
the QWidget based move events use QCursor::setPos, which doesn't reliably
go through the gesture framework.
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Done-with: Zhang Hao <zhanghao@uniontech.com>
Fixes: QTBUG-94769
Pick-to: 5.15 6.2
Change-Id: Idf650c91e5a9cffa996e23e743939243b1d4fcc0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
MoltenVK installed from homebrew has the following
directory structure:
molten-vk/1.1.5/libexec/include/vulkan/vulkan.h
molten-vk/1.1.5/include/MoltenVK/mvk_vulkan.h
Task-number: QTBUG-80576
Pick-to: 6.2
Change-Id: If6f5aeb55908f60fff49417ee1ddf4c2db980c5a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The local position needs to be corrected when the Qt receiver window
does not correspond to the native event receiver window.
Fixes: QTBUG-97095
Pick-to: 6.2 5.15
Change-Id: Ic9fa3d84b6ee84ae5f8fa2408b0d60e35dbfa328
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Emscripten complains that this variable is deprecated and should be
replaced with the one given in this patch.
Change-Id: Iafee06fcb1f292de25570545d74d7327679461b0
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
There's no need to dereference+reference a QList's iterator
only to pass the result to an algorithm, just pass the iterator.
Change-Id: I7367010f6ab489d951715259bd51aeec790d3c84
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This define used to be set for the entirety of the Qt build but
was lost during the qmake->CMake transition. Re-enable it.
Change-Id: Idc4cb6ada485158559485b60f62f76439550b255
Pick-to: 6.2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Currently using nested Q_FOREACH loops produces warnings about
shadowing local variables (if enabled). For example, this code:
QList<int> aList;
QList<int> bList;
foreach (int a, aList) {
Q_UNUSED(a);
foreach (int b, bList)
Q_UNUSED(b);
}
produces the following warning with MSVC:
warning C4456: declaration of '_container_' hides previous local
declaration
This is due to using variable _container_ as loop variable for both
loops.
This patch appends current line number to the name of the loop
variables so that most of the uses of Q_FOREACH will not result
in shadowing.
The patch originally by Benoit Regrain.
Fixes: QTBUG-79081
Pick-to: 5.15 6.2
Change-Id: I55235e917e920171b138c8b3239a95dfe2ac7988
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This amends commit 165e01d5d5.
Above commit broke the code that adds "${PROJECT_SOURCE_DIR}/cmake" to
CMAKE_MODULE_PATH. The semicolon that separates entries of
CMAKE_MODULE_PATH must be escaped. Otherwise, the semicolon separates
elements of the flags list.
Additionally, fix the QT_AVOID_CUSTOM_PLATFORM_MODULES code path which
lacked the addition of "${PROJECT_SOURCE_DIR}/cmake".
Pick-to: 6.2
Change-Id: I72f78cf066cabe6b0002dce1aa0294aa0dc9cbf0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Do not read the target property LINK_LIBRARIES from interface libraries
as this leads to errors with CMake 3.16.
This amends commit 326b91ea78.
Pick-to: 6.2
Change-Id: I44251c7633d5ecd977cd05746ac311dd1285d1e3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It is unsupported with clang-cl and breaks the build.
This is a fixup for:
51e8d3592a Let QLocale::uiLanguages() use WinRT API when possible
Task-number: QTBUG-94341
Pick-to: 6.2
Change-Id: Icf32339e81d67d4c119b7fb8d8d834c744b9ead0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This was handled correctly when the backend supplies transitions
bracketing the time in question, but the fallback code tried to use
the DST offset at the time with larger offset from UTC; this did not
work when the gap was due to a change in standard time. Discovered by
ANS1 parsing of a date-time with two-digit year, for which the
date-time parser tried to use 1921-05-01T00:00 local time when filling
in the fields it had parsed; but, when run in Europe/Helsinki, there
is no such time due to the 20m 11s skipped when joining EET from the
prior local solar mean time.
Correct the calculation to use the actual change in offset from UTC,
as used in the (far better tested) between-transitions branch of the
code, rather than the DST offset after the transition.
Add a test-case based on the ASN.1 certificate date whose parsing
revealed the issue. Although it seems nothing in Coin can reproduce
the issue, the reporter has verified that the test does indeed fail on
the system where the bug was found and the fix does fix it.
Fixes: QTBUG-96861
Pick-to: 6.2
Change-Id: I12b02bad01daca2073d1a356452cd573684aa688
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When adding resources generated via a custom command, the project fails
to configure when targeting iOS with CMake and Xcode with the error:
CMake Error in src/CMakeLists.txt:
The custom command generating
src/.qsb/TestShader.frag.qsb
is attached to multiple targets:
TestApp_other_files
TestApp
but none of these is a common dependency of the other(s). This is
not allowed by the Xcode "new build system".
This happens e.g. when using qt6_add_shaders, which adds a custom
command to generate the qsb files. Or by simply adding resources via
qt6_add_resources, which depend on a custom command.
The problem is that qt6_add_resources also adds the resource to a
second "fake" target ${target}_other_files via
_qt_internal_process_resource and _qt_internal_expose_source_file_to_ide.
See c7d1874cd1.
Since these targets do not have a common dependency CMake fails to
configure the project.
So lets fix it similar to change 1bd0a5ce02352a600367beb5a5421c8f8332e1fe
and let the ${target}_other_files depend in the main ${target}.
Pick-to: 6.2
Task-number: QTBUG-95763
Change-Id: Iecdb40993a91da8bfbf6553892f9b0722d2e886c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When parsing CSS, a border-color value is parsed as four brushes, as css
allows assigning up to four values, one for each side.
When applying the CSS to the HTML, we accessed it as a color value,
which overwrote the parsed value with a QColor. So while we had a valid
parsed value (and didn't re-parse), the code accessing that value still
expected it to be a list, and thus failed to retrieve the data.
There are several ways to fix that, but the cleanest way without
introducing any performance penalty from repeatedly parsing (and in fact
removing a parse of the string into a color) is to enable colorValue to
interpret an already parsed value that is a list without overwriting the
parsed value again. To avoid similar issues in the future, add assert
that the parsed value has the right type in brushValues.
As a drive-by, speed things up further by making use of qMetaTypeId
being constexpr, which allows for it to be used in a switch statement.
Add a test case.
Fixes: QTBUG-96603
Pick-to: 6.2 5.15
Change-Id: Icdbff874daedc91bff497cd0cd1d99e4c713217c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Because of the addition of the operator T*(), the expression "it + N"
where N was not exactly qsizetype but any other integer type was a
compilation failure because of ambiguous overload resolution.
With GCC it's apparently a warning:
warning: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
note: candidate 1: ‘QList<T>::iterator QList<T>::iterator::operator+(qsizetype) const [with T = char; qsizetype = long long int]’
note: candidate 2: ‘operator+(char*, ptrdiff_t {aka long int})’ (built-in)
With Clang, it's an error:
error: use of overloaded operator '+' is ambiguous (with operand types 'QList<int>::const_iterator' and 'ptrdiff_t' (aka 'long'))
note: candidate function
inline const_iterator operator+(qsizetype j) const { return const_iterator(i+j); }
note: built-in candidate operator+(const int *, long)
Pick-to: 6.2
Fixes: QTBUG-96128
Change-Id: Ie72b0dd0fbe84d2caae0fffd16a06f23dd56b060
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
And don't set non-default large value in QNetworkRequest's constructor.
Some servers consider those values as 'flow control error'.
Pick-to: 6.2
Fixes: QTBUG-97384
Change-Id: I801b7c83fe7e7392a02ba653c36dfa8a22c21d1e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The macro takes only one parameter, sentences must be wrapped in {}.
Pick-to: 6.2
Fixes: QTBUG-97441
Change-Id: I7177548a32a67d720c2b551d16c09d898b0fda51
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
On macOS, it is possible to right-click-open a context menu for a window
that is not active. This does not activate the window.
When then clicking into the window to activate it, the popup is closed,
but only after the WindowActivate events has been sent. This blocks the
event delivery, as QApplication (since commit 78264f333e)
interpreted activation changes while popups are open to be just delayed
focus events. The UI ends up in a broken state where focus cannot be set
on the widgets in the window.
To fix this, don't ignore such activation events on macOS. As a drive-by,
give the variables more meaningful names.
Note: We cannot call closeAllPopups before delivering WindowActivate,
as that would close the popup before the mouse event is delivered, making
it impossible to select any of the actions from the menu.
Ideally, clicking into a popup of an otherwise inactive application would
not activate that application (that is the default behavior for native
macOS applications), but that's out of scope for this patch.
Fixes: QTBUG-78750
Task-number: QTBUG-69710
Task-number: QTBUG-66513
Pick-to: 6.2
Change-Id: I6344370ae7be31630e37514e04918b2d6cb8b69a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The test passes, the functionality is implemented in QCocoaWindow.
Task-number: QTBUG-8857
Pick-to: 6.2
Change-Id: I2f4b3a39cec1aaaf4351753b590f35e280503461
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The documentation snippets name the result of dotProduct()
"lengthSquared", but it is just a coincidence, not the property of dot
product of two different points. Just name the result `dotProduct`
without claiming any properties.
Also fix the type of the result in the QPointF case.
Fixes: QTBUG-94979
Change-Id: I4c337dd8335953489eac86c07a219c0a2d232369
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When using the Freetype font database, we would ignore the
typographical width of loaded fonts, which could make it
impossible to select certain fonts in a family.
[ChangeLog][Freetype] Fixed a bug where fonts of different
width within the same family would be unselectable if the
Freetype font database (no-fontconfig configuration) was in
use.
Pick-to: 5.15 6.2
Fixes: QTBUG-89640
Change-Id: Ic9c17a7c3cc14eb7e942b05d6b21b7c1602816cf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Retaining texture upload commands comes at a price, because it
means we also retain the backing storage, which could e.g. be
fullscreen buffers for applications on Wayland. These would
eventually be overwritten, but just clearing the array between
frames is also fine because the data is never reused and the
array is a QVarLengthArray anyway so it already has a lot of
reserved space.
Pick-to: 6.2
Change-Id: I7389487be67b671830787e30e1468c303b7ac5c2
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
On low-end hardware without fast framebuffer clears one can
significantly reduce the fill rate by disabling framebuffer clears
(provided, as it's usually the case, that the application has content
filling the entire framebuffer).
Add a couple of environment variables to do so, one to disable all
clears and one to disable only color clears (in case the surface is
requested without a depth buffer). Note that disabling all clears
on a surface *with* a depth buffer still requires
QSG_NO_DEPTH_BUFFER to be set, otherwise QtQuick is going to assume
that there is a clean usable depth buffer.
Change-Id: I96ad0a3d28dd0ab65cc960fb7cb2e0a8b6f35628
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
