Commit 3695b35dfc accounted for pointer to
other incomplete types, but pointer-to-void was missed. This caused an
inconsistency in the stored metatype for void*, which is a built-in type
(QMetaType::VoidStar) but no pointer was recorded.
The test in tst_moc hadn't been enabled because the functions in
questions weren't extracted by moc. That is fixed in this commit.
Change-Id: I6f936da6f6e84d649f70fffd1706f613517a75fb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previously, we were storing all binding-observers in a list, so that we
can later revisit them during the notification loop.
However, there is no point in doing that when the binding did not
actually change.
Pick-to: 6.4
Change-Id: I0b3343cc442eca2586c7c6a10c31d780f04730e6
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The problem was introduced in the atomic code path only, the legacy
one has always specified the correct crtc id.
Amends 56149c0fbb.
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: Ie3a99ec4bc24901e1303631097a395fde8dbe110
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
...by removing the entire adjustedFormat() helper.
Qt Quick has never used this, which indicates it is not that
useful. Same goes for Qt Multimedia or Qt 3D. Ensuring depth and
stencil is requested is already solved by using
QSurfaceFormat::setDefaultFormat() or by adjusting the formats
everywhere as appropriate.
The helper function's usages are in the manual tests that use it as a
shortcut, and in the GL backend itself. Remove it and leave it up the
client to set the depth or stencil buffer size, typically in the
global default surface format. (which in fact many of the mentioned
manual tests already did, so some of calls to
window->setFormat(adjustedFormat()) were completely unnecessary)
By not having the built-in magic that tries to always force depth and
stencil, we avoid problems that arise then the helper cannot be easily
invoked (thinking of widgets and backingstores), and so one ends up
with unexpected stencil (or depth) in the context (where the GL
backend auto-adjusts), but not in the window (which is not under
QRhi's control).
It was in practice possible to trigger EGL_BAD_MATCH failures with the
new rhi-based widget composition on EGL-based systems. For example, if
an application with a QOpenGLWidget did not set both depth and stencil
(but only one, or none), it ended up failing due to the context -
surface EGLConfig mismatches. On other platforms this matters less due
to less strict config/pixelformat management.
Pick-to: 6.4
Change-Id: I28ae2de163de63ee91bee3ceae08b58e106e1380
Fixes: QTBUG-104951
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Problem description:
--------------------
Assume we have two properties, P1 and P2. Assume further that we assign
a binding to P2, so that it depends on P1. Let the binding additionally
capture some (non-QProperty) boolean, and only create the dependency to
P1 if the boolean is true.
The state afterwards is
P1:[p1vaue|firstObserver]
|
|
v
---[p2binding]
/
P2:[p2value|binding]
If the boolean is set to false, and P1 changes its value, we still
correctly re-evaluate the binding and update P2's value. However, during
binding evaluation we will notice that there is no further dependency
from P2 on P1, and remove its observer.
The state afterwards is
P1:[p1vaue|firstObserver=nullptr]
---[p2binding]
/
P2:[p2value|binding]
Then, during the notify phase, we traverse the observer's again,
starting from P1's firstObserver. Given that it is nullptr now, we never
reach P2's binding, and thus won't send a notification from it.
Fix:
----
We store a list of all visited binding-observers (in a QVarLengthArray,
to avoid allocations as long as possible). After the binding evaluation
phase, we then use that list to send notifications from every binding
that we visited. As we already have a list of all bindings, we no longer
need to recurse on binding-observes during the notification process;
instead, we only need to deal with static callbacks and ChangeHandlers.
The pre-existing notification logic is still kept for the grouped update
case, where we already have a list of all delayed properties, and should
therefore not encounter the same issue. Unifying its codepath with the
existing logic is left as an exercise for a later patch.
Fixes: QTBUG-105204
Task-number: QTBUG-104982
Pick-to: 6.4 6.3 6.2
Change-Id: I2951f7d9597f4da0b8560a64dfb834f7ad86e757
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Until Qt 5.15, PlaceholderText color was automatically derived from the
Text color, dimmed by 50% (set alpha to 128, assuming the text color
is fully opaque).
This method has been adapted in the static qt_fusionPalette() method.
No other static method to populate palettes defines a PlaceholderText
color. As a consequence, the Text color is used to render placeholder
text characters.
This patch adds a static method, that sets missing PlaceholderText
colors by deriving them from the corresponding Text color.
It takes a dim factor by which the opacity is reduced versus the
corresponding Text color.
Fixes: QTBUG-105049
Pick-to: 6.4 6.3 6.2
Change-Id: Iebb9d15d56f5d72d7ec68b7a0babdf5825b92665
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Play nice with old renderers like the OpenGL paint engine for
QPainter.
When combining Qt Quick and QPainter targeting the same GL window,
calling QQuickWindow::beginExternalCommands() is not currently
sufficient to ensure problem-free operation, it also needs a
QQOpenGLUtils::resetOpenGLState() afterwards to get rid of the buffer
bindings. (which is important when using legacy code with client-side
vertex arrays) Which in turn is not what the documentation promises,
so resetting the bindings is now ensured on the rhi level when
Qt Quick calls beginExternal().
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-104801
Change-Id: Ibd82753996768aad0118bff87d4e1f8bcc388c58
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The problem is reported in combination with the new 6.4 way of
handling texture-based widgets, but this looks like something that has
always been missing:
Setting WA_TranslucentBackground changes the QWidgetWindow's format,
and this is done upon calling setAttribute(). That's good for most
cases, but the changes to the QWindow's format are lost when the
window is destroyed and then the widget gets another window
later. This is not that common, but can happen.
For example, if a top-level widget is parented under something else,
and then later it is parented to null again, so that it is toplevel
once again, background transparency can be lost because nothing
re-evaluates the WA_TranslucentBackground flag after the initial
setAttribute(), and so the widget's second QWidgetWindow is not set up
accordingly (because this new QWindow may not have alpha specified in
the QSurfaceFormat which may or may not be a problem, depending on the
platform / windowing system)
The simple solution is to evaluate the attribute not just when setting
it, but also when a new QWidgetWindow is created for the widget.
Fixes: QTBUG-104952
Pick-to: 6.4
Change-Id: I92746caea5561544f90395d5473ac28d43143924
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The path for is_mac is unused. Use it by querying the platform from the
new WASM plugin web platform API.
Task-number: QTBUG-105213
Change-Id: I9a8922b5e9d215090dbdcc534c056c2cc068c009
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
We pass a pointer to uninitialized memory to QMetaType::create().
There's no harm because we're using the invalid QMetaType, but GCC is
actually right to complain for any other type.
qtestcase.h:54:25: warning: ‘buf’ may be used uninitialized [-Wmaybe-uninitialized]
qmetatype.h:454:11: note: by argument 2 of type ‘const void*’ to ‘void* QMetaType::create(const void*) const’ declared here
Pick-to: 6.3 6.4
Change-Id: I3859764fed084846bcb0fffd1703eb7967acf0d7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
All of those are implicitly-shared Qt data types whose copy constructors
can't throw and have wide contracts (there aren't even any assertions
for validity in any of them). These are all types with a QVariant
implicit constructor, except for QCborValue, which is updated on this
list so QJsonValue (which has a QVariant constructor) is also
legitimately noexcept.
To ensure we haven't made a mistake, the Private constructor checks
again.
Change-Id: I3859764fed084846bcb0fffd17044d8319a45e1f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Commit 2f0a625fd4 added noexcept for
these, but didn't verify that the operation itself was noexcept. And it
wasn't on 32-bit systems, because sizeof(void *) is only 4 bytes, making
QVariant and QVariant::Private a mere 12 bytes. That's insufficient for
QUuid and for almost all geometric types when qreal==double.
We can't use sizeof() in qvariant.h because most of those classes are
only forward-declared.
Change-Id: I6f936da6f6e84d649f70fffd1705ce948891d06a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QRegularExpression::match (and globalMatch) is currently overloaded
for QString and QStringView. This creates a subtle API asymmetry:
QRegularExpression re;
auto m1 = re.match(getQString()); // OK
auto m2 = re.match(getStdU16String()); // Dangling
This goes against our decision that every time that there's a possible
lifetime issue at play, it should be "evident". Solving the lifetime
issue here is possible, but tricky -- since QRegularExpression
is out-of-line, one needs a type-erased container for the input
string (basically, std::any) to keep it alive and so on.
Instead I went for the simpler solution: deprecate match(QStringView)
and introduce matchView(QStringView) (same for globalMatch). This
makes it clear that the call is matching over a view and therefore
users are supposed to keep the source object alive.
Drive-by, remove the documentation that says that the QString
overloads might not keep the string alive: they do and forever will.
[ChangeLog][QtCore][QRegularExpression] Added the matchView()
and globalMatchView() functions that operate on string views.
The match(QStringView) and globalMatch(QStringView) overloads
have been deprecated.
Change-Id: I054b8605c2fdea59b556dcfea8920ef4eee78ee9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qcontainerfwd.h was relying on the forward declaration of QByteArray in
qglobal.h, so add the missing forward declaration there.
Additionally, had to move the implementations of qTzSet() and qMkTime()
to qenvironmentvariables.cpp along with environmentMutex.
Task-number: QTBUG-99313
Change-Id: I233aff305c2fedaf0a48362cc99ff2d6f6c0ee54
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
As a drive-by, fixed the sorting order of header includes.
Task-number: QTBUG-99313
Change-Id: I731e397f8488460657b31839c49f07ff3c476c66
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Warn projects not to use it because PUBLIC_LIBRARIES don't make
sense for executable targets and it also led to some issues in the
internal functions where some of them did not expect to receive
PUBLIC_LIBRARIES.
To ensure builds don't needlessly break, treat PUBLIC_LIBRARIES values
as regular LIBRARIES. In the future we might add an error instead.
Using PUBLIC_LIBRARIES in qt_internal_add_app, etc, accidentally
worked because the option name and the values following it were
parsed as values of the "previous" option, like SOURCES or
INCLUDE_DIRECTORIES or LIBRARIES, and when those got
passed through to qt_internal_extend_target, things magically worked.
We have a lot of projects using PUBLIC_LIBRARIES, mostly due to the
way qmake pro files were written and how pro2cmake converted them.
We'll have to clean up each repo.
Change-Id: I69e09d34afdf98f0d47c08d324643fc986f8131c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Use the WinRT API to read the basic colors, and construct a usable
palette from those. None of the Windows.UI.ViewManagement.UISettings
APIs returns a full set of usable colors -UIElementColors returns the
old system colors, or useless values. And UISettings::GetColorValue only
gives access to a basic palette, where e.g. the background color is
just black, which doesn't match what Windows itself uses.
However, we know if we want to be dark or light, and can construct a
palette from the basic colors. The most relevant color to read from the
system is the accent color.
In the course of doing that, refactor and clean up the code somewhat to
standardize the handling, and remove hardcoded color values as much as
possible.
This is opt-in: unless the application is started with the QPA darkmode
parameter set to 2, nothing changes.
Pick-to: 6.4
Task-number: QTBUG-72028
Change-Id: If603bb34c8f7478a05aafef2552a67e1e3460d29
Reviewed-by: Marius Kittler <mariuskittler@gmx.de>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The comment suggests that there should be function declarations that
need QDataStream, but there are none. It's probably a leftover from the
old code.
Change-Id: Iacefccc6b862d9a4ec111ebac8970b1ef01bcf39
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Until we've checked the stored meta type, we don't know what the Private
contains. We only formed a reference to said value, so we should be
safe, but why tempt it?
Change-Id: I6f936da6f6e84d649f70fffd1706095fc6228755
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@gmail.com>
This reverts commit 2f5f276b4a,
after which valid printers are no longer listed anymore.
Fixes: QTBUG-105242
Pick-to: 6.2 6.3 6.4 5.15
Change-Id: I6a388acff2a8033ad1052319edcf7e41a2f72c8f
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
So the compiler doesn't feel like it must emit these functions. They're
not used outside of qmetaobject.cpp.
Change-Id: I36b24183fbd041179f2ffffd170228c6e94b5f9b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We don't need to copy the candidate name into the QVarLengthArray buffer,
we just need that buffer for the parameters.
Change-Id: I36b24183fbd041179f2ffffd17021ba2fd2b8251
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Like in the previous commit, use QMetaMethodPrivate::invokeImpl() to
avoid having to reconstruct the method signature.
Change-Id: I36b24183fbd041179f2ffffd17021c7a0bfa48c0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Use the QMetaMethodPrivate::invokeImpl() function we added in the last
commit, without recreating the method signature. Instead, only do a
comparison on the method name and allow invokeImpl() to decide whether
this method can be called with the given arguments. This will allow
invokeImpl() to have more flexibility in deciding if the arguments match,
using the stored metatype information.
Change-Id: I36b24183fbd041179f2ffffd17021a86484bfab6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This adds an internal method to QMetaMethodPrivate to do the work of
actually placing the call on a given meta method. This rewrite should
make the code clearer, but make no otherwise perceptible difference in
behavior.
The next commit will rewrite QMetaObject::invokeMethod to use this new,
internal function to avoid doing a lot of string allocations.
Change-Id: I36b24183fbd041179f2ffffd170219c0deaaf7f5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Use a well-known idiom for finding a matching window in the window stack
(std::find_if)
Change-Id: I677ef6ad8ee88bbd9eee1405be592ec2527ca3b9
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Needed to get rid of warnings like
CMake Warning at cmake/QtFindPackageHelpers.cmake:406
(message): Could not find target Qt6::BundledLibYaml to query
its package name. Defaulting to package name Qt6BundledLibYaml.
Consider re-arranging the project structure to ensure
the target exists by this point.
which were introduced with the integration
of dffcc2370e in qtbase.
This happened because we never set and exported the package names
for 3rd party bundled libs.
So export the package name as well as "is 3rd party lib" value.
Amends 6235f7fa62
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I25fc1ffef766198974025e0097bced1cca4dd28d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If another spawned thread will log at the same time
a crash was possible because IgnoreResultList
was not thread-safe.
Task-number: QTBUG-104840
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I251c83bb28cb75e55d477706bf2524c061a6eab7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
No fields in QWasmCompositedWindow, apart from visible, are used for any
computation. They were write-only. Remove the class entirely and create
a hash of visibility state instead.
Fixes for z-order will follow.
Change-Id: Icb7ff1865d1f9a67c0fde43cfa331ca1242ebcaa
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Commit 42d0089d44 added support
for multiple root paths. This works fine but it also added
"options->inputFileName" as fallback if nothing was provided.
The inputFileName cannot be used as root path (directory).
So let's use absolutePath() of that file.
Pick-to: 6.4 6.3 6.2
Change-Id: Id76a2cd79a82966bdac8240644b3c03ac4248066
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It is clearly not temporary anymore, nor is the reference to
qsslsocket_winrt useful.
Change-Id: If746959ddaf8ee564a62b4d168306c79aa466026
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The certificate was updated recently and doesn't have the same
deprecated hash functions and small key size as the old one did.
Change-Id: I301ad50a96a30483b92a6e30f61e78e8d6b955ca
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Eliminate needless linebreaks. Use ranged-for to simplify a loop. Use
a startsWith() check for BOM and sliced() to take it into account. Use
ternary in initializers rather than initializing a bool to then use in
a ternary. Make explicit that some values are const. Use std::move()
on a QVariant to save copying.
Change-Id: Ie97da14906357803f8d5ada2e376b809f14bba54
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
This is in use in tst_qdbusinterface.cpp, so let's have it here to make
sure it works:
QVERIFY(QMetaObject::invokeMethod(&iface, "ping",
Q_RETURN_ARG(QDBusVariant, retArg),
Q_ARG(QDBusVariant, arg),
Q_ARG(QDBusVariant, arg2),
Q_ARG(QDBusVariant&, retArg2)));
Change-Id: I36b24183fbd041179f2ffffd170271424c048292
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We should fail to even find the method. `QString' and `QString&` are not
compatible.
Change-Id: I36b24183fbd041179f2ffffd170259bcf07fd459
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The type MyUnregisteredType needs to be only forward-declared for the
trick to work. The issue is not about registration, because since commit
fa987d4441 ("MetaObject: Store the
QMetaType of the methods"), we will record the meta type of the type
anyway, which will eventually allow the meta object to actually find
this type.
Instead, the tests are valid for a type that is only forward-declared.
Change-Id: I36b24183fbd041179f2ffffd1702182746f7c1b2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The #ifdef wasn't necessary because destroy() had been using
__STDCPP_DEFAULT_NEW_ALIGNMENT__ without #if.
Change-Id: I3859764fed084846bcb0fffd17039570283d3eaf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Instead of placing the error deep into IsPointerToTypeDerivedFromQObject
with a message about weird the sizes, move them closer to the front-end
so we get a proper error message like:
<stdin>:1:56: required from here
qmetatype.h:1131:45: error: static assertion failed: Meta Types must be fully defined
<stdin>:1:50: required from here
qmetatype.h:1132:29: error: static assertion failed: Meta Types cannot be non-const references or rvalue references.
<stdin>:1:56: required from here
qmetatype.h:1136:55: error: static assertion failed: Pointer Meta Types must either point to fully-defined types or be declared with Q_DECLARE_OPAQUE_POINTER(T *)
This does not apply to the meta type list stored in a meta object, as
meta method parameters may be opaque pointers or even forward-declared
only.
Change-Id: I36b24183fbd041179f2ffffd17025f10f38e04e6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
