It was shown to have poor performance compared to contains() and
insert().
Pick-to: 6.7 6.6 6.5
Change-Id: I61cfbc8c34e325d677d7954118ef68057df640cb
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
By not assuming we will have resized.
reserve(size() + 1) will have suffered a bit from this, but
that is probably not very common.
Change-Id: I8750d430f532a72729ed06e67c0f315707a916d6
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
cfd935fe6c26800befc10889afc0aebde311acca removed the erroneous mapping
from XKB_KEY_XF86Calculator to Qt::Key_Launch1, leaving it unmapped.
It should be mapped to Qt::Key_Calculator, just like
XKB_KEY_XF86Calculater.
Fixes: QTBUG-121713
Pick-to: 6.7 6.6 6.5
Change-Id: Iaa28e38792f43a7950a3c38397869a6ffed332d1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
It's not the _WITH_TIMEOUT variant (the timeout is missing).
Amends a change preceding b24bb12f6a93b98e9bc44c99e151b995eb7cea71,
the commit that moved all the documentation into qtestcase.qdoc in the
first place. I didn't track the change back further than that.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: I79ccd84a5dbed20012fa1a2d3561945f8a7638d5
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
List might be a reference type, in which case it won't have any members.
Pick-to: 6.7
Change-Id: Iac2c08c42f31ebc67b31be157f73ae318d328a18
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
All calls to the fromVarArg() conversion helper are made with JNI types
from a va_arg list, so they have to be either primitive types, or a pointer
(jobject, which internally is a _jobject *). There's no benefit from
moving those or passing them by reference; the most efficient convention
is to pass them by value.
Pick-to: 6.7
Change-Id: I6fed9b202be3c6a265117684fecd51d03ccbb534
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
When declaring native callback functions with the JNI type system, then
we actually register a helper function with variadic arguments, and
implement that to forward the arguments to the declared function, which
then might use higher-level types as arguments. We deduce those
higher-level types through a variadic template, and use std::tuple as
well as std::apply to generate the calls.
Simplify the implementation by using std::make_tuple, and replace
q20:remove_cvref_t with std::decay_t; this is what std::make_tuple uses,
and we don't need to maintain functions and arrays as such.
Found during 6.7 header review.
Pick-to: 6.7
Task-number: QTBUG-119952
Change-Id: I7cd206c6b372c2ec62a10feb5f9253f5607f01a9
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Amends 83e5d74864a8780445db4b34e406afc53b331039.
A model index returned by QFileSystemModel might become invalid when
events get processed, so don't store the result of setRootPath to re-use
it in a QTRY_COMPARE function. Instead, always ask for a fresh model
index.
Also, use std::chrono::duration::count correctly; it returns the "tick",
not the corresponding milliseconds, so (10s).count() returns 10 instead
of 10000. Explicitly use 10000ms here.
Un-blacklist the test on macOS again.
Task-number: QTBUG-74471
Pick-to: 6.7 6.6 6.5
Change-Id: Ic98bb53c696441131bbc1055b64822faf2aec96f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The "qt" meta-catalog is some relic from the past that pulls in the
translations for qtbase and qtmultimedia. The qtbase translations are
deployed by default, and the qtmultimedia translations are deployed if
qtmultimedia is used by the project.
Pick-to: 6.7
Change-Id: I53e5920d39f87162c418fb3f4cff7927ec9b5488
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since QVersionNumber doesn't have an existing way to modify individual
segments, provide only const_iterator.
[ChangeLog][QtCore][QVersionNumber] Added (const) iterators over
segments (begin()/end(), incl. c- and r- variants).
Change-Id: Ia9af70c2a9c59f630123894ad2c9f38031ef5b8f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... use it in QKeyValueIterator.
This is somewhat simpler than the old QKeyValueIterator::pointer.
I don't think the pointer::operator*() could have ever worked, because
it returns value_type&, but is const.
That leaves the defaulted copy and move SMFs as a difference (ArrowProxy
is using aggregate initialization, so doesn't need any), and the fact
that operator->() is const.
Change-Id: I80b9c5f696de6ae30f3939166b205b9213eac57e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This was in the 6.2 and 5.15 versions of the script, but not in dev,
6.7, 6.6, 6.5, and so was promptly forgotten.
Pick-to: 6.7 6.6 6.5
Change-Id: Ic0a1708a29eccd7efe41aa4670ea55f1edb6be0b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Can't do it now, because this non-polymorphic class is exported
wholesale, so removing the SMFs would be BiC. But pre-program for
Qt 7, so we don't forget again.
Change-Id: I36420dbaeda53391d304cf6832167f6157c22e35
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In Qt 5, a QBitArray could not contain more than INT_MAX bits, because
the then-size_type, int, cannot represent more, even if the underlying
storage could hold 8x as much, and the serialisation format, using
unsigned int, could represent 2x.
Therefore, reject old formats with sizes that exceed INT_MAX elements
as corrupt.
Likewise, the Qt 6 serialisation format unconditionally uses 64-bit
sizes, but 32-bit platforms still cannot represent more than
numeric_limits<qsizetype>::max() (= INT_MAX) bits in memory. This is a
valid stream for 64-bit platforms, though, so ideally, this should be
using SizeLimitsExeeded, which, however, is only available from Qt
6.7. So, for now, and until we have SizeLimitsExeeded, mark the stream
as corrupt here, too.
[ChangeLog][QtCore][QBitArray] Fixed undetected overflows in the
deserialisation (opertor>>()) from QDataStream.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: Ib24cf9218c06a3a05185723c77d4313611c2dd40
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Bundled 3rdparty libraries link Qt platform targets implicitly, which
lead to the dependency resolution when the library is used by another
targets. For qtbase this works just fine since all platform targets
are not imported and they are used from a build tree. But in case if
3rdparty library is built as part of Qt repo different from qtbase
platform targets are imported and trigger the global promotion in
CMake. Usually qt_find_package for the 3rdparty libraries is called
somewhere in src/... directory and since Qt::Platform* targets are
already created in the top-level repo CMakeLists.txt by the
find_package(Qt ...) call, this leads to an error.
The propsed fix forces the global promotion of Qt platform targets
as soon as they created by the one of the initial find_package(Qt ...)
calls.
Change-Id: Iceb53f9ecccbdc438f9bc3bcc836583cfd4de535
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Currently we assume that only modules that have plugins built in the
current build tree need to generate and install the
Qt<Module>Plugins.cmake file. This approach is weak since other Qt
modules might still want to provide the plugins of the certain types,
even if the module that the plugin type belongs too didn't have plugins
initially.
The fix unblocks the formally 3rd-party plugin installation and loading
chain.
Pick-to: 6.2 6.5 6.6 6.7
Fixes: QAA-2266
Change-Id: Ifc616e26a00674371c8e2fe2ca12237d153e5707
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This change will allow Shiboken to generate proper bindings as otherwise
the python code will get an anonymous parameter which is not really
helpful for understanding the role of the parameter nor explicitly set
it.
Fixes: QTBUG-121468
Change-Id: I02943223eef99d815ef68e9603736cc064843fb0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Embedded loader was missing style set up, leading to a crash
when platform theme style data was loaded. As a drive by, change
the style set up to use Context instead of Activity, since it doesn't
require Activity.
Fixes: QTBUG-119532
Pick-to: 6.7
Change-Id: I434233e173cc2c90d981bbf2aa0044117a20b17f
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
- Match QCOMPARE logic when printing stringlists that don't match, it's
"actual" then "expected"
- Use row tag names that don't interfere with the shell; e.g. using
`tst_qdiriterator iterateResouce:':/testdata'` doesn't work for some
reason, so just add a qrc prefix
Change-Id: I3d556b83ec34f2dab15ea3178273af10fb2c62e6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The FreeType font engine would wrongly claim to support scaling
transforms for bitmap fonts, despite ignoring the transform
later. We do support this for color fonts through special casing,
but for other bitmap fonts, we should return false and let the
paint engine handle the scaling instead.
Fixes: QTBUG-111796
Change-Id: I31732b909ef6e0c1afbf01ed4de1f67e994934c3
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since QCalendar is non-trivial, parameters of this type should not
have a default in the declaration; better to have an overload set with
the calendar-less overload out-of-line passing the default.
This actually restores signatures that existed previously, but that
were merged with the QCalendar-taking overloads at Qt 6.
Pick-to: 6.7
Fixes: QTBUG-121528
Change-Id: Ib10ced67a2398108a31c7e95d5e865b7959bed4d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
...that mentions that they're only needed for advanced use cases that
aren't covered by the higher level deployment commands.
Pick-to: 6.7
Task-number: 121708
Change-Id: Id31aece7ae7685ea5f4940e6c4adf62ae8216528
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The tables allows us to show how the parameters correspond to variables,
and it gives us the ability to add notes.
Add the note that LIBEXEC_DIR is available since 6.7.
Pick-to: 6.7
Task-number: QTBUG-121708
Change-Id: I9421bdc692b0df45dc356c17fb90da8799d18ef9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...or rather when it's used with the generic deployment tool.
Pick-to: 6.7
Task-number: QTBUG-121708
Change-Id: I161564923a43c82150f581874ba20a9ad6de310f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To aid readability.
Task-number: QTBUG-121398
Pick-to: 6.7
Change-Id: I3cb231584c2b7aee72e9f01c669fed1e01fbe475
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
cxx11_future flag should be disabled for VxWorks. VxWorks still does
have some bugs related to this std features and some parts of code needs
to be excluded. At least till the 24.03 VxWorks release as for now this
is the expected release that should contain fixes.
Task-number: QTBUG-115777
Change-Id: Ic652403697d727f4ae05ae7287ff8285075d3802
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add indent to the title if groupbox alignment is set to Qt::AlignLeft |
Qt::AlignVCenter.
Fixes: QTBUG-121049
Pick-to: 6.7 6.6
Change-Id: I25e2fe4e73b920baf4c678b6b0e758d1da7cf632
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
It appears to be used only in qlalr, which is, however, not
bootstrapped.
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: Idc16d957bf687238c7b0ee603d8b092e2048ef18
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This test uses socketpair which is not available on vxworks, so it fails
to compile.
Task-number: QTBUG-115777
Pick-to: 6.7
Change-Id: I46f3b4ebd937dc4ca2511381dd58451434e6a2fc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
According to the documentation:
GL_INVALID_OPERATION is generated if the combination of internalFormat, format and type is not one of those in the tables above.
https://registry.khronos.org/OpenGL-Refpages/es3.0/html/glTexImage2D.xhtml
We were allowing the RGB values be passed as RGBA, after this change we
don't do so anymore.
This would result for KWin in:
Mesa: User error: GL_INVALID_OPERATION in glTexImage2D(format = GL_RGBA, type = GL_UNSIGNED_BYTE, internalformat = GL_RGB8)
Pick-to: 6.5 6.6 6.7
Change-Id: Ifde8a570eff01be573f780655d8cedbb96f5ba2b
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The boundingRect and controlPointRect did not use the start point from
the `QPainterPath(const QPointF &startPoint)` constructor until the
`dirtyBounds` or `dirtyControlBounds` member variables were set to true.
Those two are false on construction. This bug was fixed by adding a new
constructor for QPainterPathPrivate that initializes the `elements`,
`bounds` and `controlBounds` member variables with the start point from
the constructor.
There is also an autotest to verify that the top left of the
boundingRect and controlPointRect are at the same position as
elementAt(0) when the start point constructor is used.
[ChangeLog][QtGui][QPainterPath] boundingRect() and controlPointRect()
now use the start point from QPainterPath(const QPointF &startPoint).
Pick-to: 6.7 6.6 6.5
Change-Id: I7bf30364406c14ed60f75d24b78a9a5535f75d93
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Unlike other containers, a QBitArray's size() is not limited by
storage, but, esp. on 32-bit platforms, its size_type: A INT_MAX
size() QBitArray only requires 256MiB of storage.
So we can't rely on "won't happen in practice" here and need to avoid
the potential UB (signed overflow) in the (size + 7) / 8
logical-to-storage-size calculation by using unsigned arithmetic.
Use the opportunity to Extract Methods storage_size() and
allocation_size(), which differ by one (d[[0] contains the size() mod
8), making it clear what's what.
[ChangeLog][QtCore][QBitArray] Fixed a bug with QBitArrays whose
size() came within 7 of the size_type's maximum.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: I5d94bae9c9c210ba1e36f8cf03609125c81bd15d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
I've noticed that on some Windows systems, the resolver refuses to
resolve IPv6-only addresses. But it can still do reverse resolution from
IPv6.
Change-Id: I5dd50a1a7ca5424d9e7afffd17adfe739ded932e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Our ideal scenario was to run python to run its getnameinfo()... so just
use getnameinfo() directly. This also avoids the problem of Python not
being present and our falling back to nslookup.
Pick-to: 6.7
Change-Id: I5dd50a1a7ca5424d9e7afffd17adfc830386306f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Add classes that make it possible to add QML as a View into
a native Android app:
QtView: Base class for QtQuickView, handles non-Quick dependent
operations. In essence a Java ViewGroup class which loads a
QWindow and embeds it into itself.
QtEmbeddedLoader: Extends QtLoader for embedded case, creates the
embedded version of QtActivityDelegate and provides an embedded-specific
path to loading Qt libraries (Mostly just allows users to set the name
of the main lib)
QtAndroidWindowEmbedding namespace: Deals with calls from
QtEmbeddedDelegate to create/destroy QWindow and from QtView to
show the window.
Take the QtEmbeddedDelegate introduced in an earlier commit
into use, and add functionality for loading QWindows for
QtViews and managing QtViews into it.
Add a factory for creating instances of QtEmbeddedDelegate.
The factory holds a map of QtEmbeddedDelegate objects and
creates them, with the Activity as the key. This is to make
it so that the same delegate can be used by multiple views
which share the same Context.
Known issues left:
* keyboard focus not working, as with other child windows
Pick-to: 6.7
Task-number: QTBUG-118872
Change-Id: I94a5f9b4f904c05cc6368cf20f273fcf10d31f17
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This partially reverts 4ecbe42ff44ace881ed4962744e9cd6c8fa65dab .
The discussion is still ongoing to decide whether the new overload
should take a QBAV or QAnySV. See
https://codereview.qt-project.org/c/qt/qtbase/+/514588 for the details.
For the time being remove the new overload from the API so that this can
be backported to 6.7 (while keeping both dev and 6.7 in sync to ease
future backports).
Pick-to: 6.7
Change-Id: I4a279653d1941faeafd95dde7a8c741009c00c72
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In the QtWindow constructor, creation of the layout and setting
the parent window were posted on the Android UI thread, leading
to them being called at a later point. If QAndroidPlatformWindow
did not have a parent at the point it was created in, but
setParent() was called shortly after, the QtWindow.setParent()
call with the actual intended parent got invoked before the
Runnable posted in the constructor got ran, leading to the
parent being overwritten with the null one passed to the
constructor, essentially leaving the QtWindow as a top level
one, while the QAndroidPlatformWindow was a child window.
The above would happen more often with foreign child windows,
sometimes causing hang ups when the parent of the foreign
child window was shown.
Creating the QtLayout outside of the Android UI thread seems
to be safe, as long as we only modify its view hierarchy inside
it.
Pick-to: 6.7
Task-number: QTBUG-116187
Change-Id: If1ed1983f5d6ba56e625148ee6a61771234a2aa1
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
QHttpHeaders uses QASV for the header name field, and this aligns
these functions with that. Furthermore having QASV as a parameter
will allow a wider range of string types to be passed as a
parameter (convenience).
Resulted from API-review
Amends: 56bb4ac484adb544925b6d7b58e4fd1d77d49503
Pick-to: 6.7
Change-Id: Iff42b75393b6470a2c34a1913dbe615bf21238db
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
These exhibit the problem described by a recent bug report.
Task-number: QTBUG-121485
Change-Id: Ia09acfa22e687ba096091a73f30df1ffd22a6e32
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
There were three things going on in this test (itself a sufficient
reason to split it up):
* Some reporting and checking of the default locale; the reporting is
duplicated in defaulted_ctor() and the check fitted more naturally
there.
* Checks that various combinations of language, script and territory
got resolved according to likely-subtag rules. These were handled
via a macro and natural candidates to become data-driven.
* A test that territory is preserved when it's the only given tag
(with a few known exceptions); broken out as a steparate test.
In the process, give the data-rows of the likely-subtag parts names
that let me extend their testing to also test construction from
string. The territory-only cases can't support that, as QLocale
doesn't support und_* forms of tags for unspecified language.
Change-Id: Id9f0fc46f30eb887b47931bad1619255acb44266
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
