According to QUIP-18 [1], all test files should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I26d72e8de04d4c7c57b3b7838af5d033265de5ba
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The test doesn't need it; qWaitForWindowExposed is sufficient.
Fixes: QTBUG-104022
Pick-to: 6.2 6.3 6.4
Change-Id: I7e818b2f377bf5798e881100c555d54482ee3dbf
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Apparently looking up a property can cause it to be evaluated (and its
signal handler called directly). From the debugging the following is
visible:
1) assume signalName is set first and target has a pending binding (not
evaluated yet)
2) once signalName setter is triggered, it calls the relevant signal
handler - onSignalNameChanged, which subsequently calls qtest_update()
3) in qtest_update():
a. we first check whether there's any old state
"if (qtest_prevTarget != null)" -> there's none yet, because we entered
this function for the first time ever -> jump to:
"if (target != null && signalName != "")"
b. once at "target != null" the engine attempts to get the value of the
`target` property. if the property `target` happens to have an unevaluated
binding, it is evaluated immediately.
[the logic is in QObjectWrapper::getQmlProperty() which calls
QObjectWrapper::getProperty() and that one calls
QQmlData::flushPendingBinding()]
c. the binding evaluation causes onTargetChanged signal handler to trigger
which in turn again enters qtest_update
4) in the "recursive" call of qtest_update():
a. same as 3.a.
b. target is now evaluated and signalName is evaluated as well (due to
being already set at step 2)
c. "if (target != null && signalName != "")" succeeds and we proceed to
connect to spy.qtest_activated
d. we return from this function and get back to the outer qtest_update()
5) we are now back at 3.c in qtest_update():
a. target is evaluated, signalName is known, so
"if (target != null && signalName != "")" succeeds -> again, we proceed
to connect to spy.qtest_activated (for the second time now - see 4.c)
b. we return from qtest_update() (the outer one) back to onSignalNameChanged
6) the end. bottom line:
- two signals were connected to target[signalName]
- zero signals were disconnected
This seems like a very nasty thing to have in a UI-centric language
but for now let's just attempt to fix the SignalSpy class
Pick-to: 6.2
Task-number: QTBUG-98722
Change-Id: I70f11000b8383e6a8fc82d0034c62a2094f6d832
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previously each test would include and build sources from the shared
folder. Now we make those sources a library, build it once, then have
each test link to it instead.
We also take the opportunity to move some helpers that qtquickcontrols2
had added into the quicktestutils library where it makes sense, and
for the helpers that don't make sense to be there, move them into
quickcontrolstestutils.
We add the libraries to src/ so that they are internal modules built as
part of Qt, rather than tests. That way we can use them in a standalone
test outside of qtdeclarative.
Task-number: QTBUG-95621
Pick-to: 6.2
Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
From now on we prefer nullptr instead of 0 to clarify cases where
we are assigning or testing a pointer rather than a numeric zero.
Also, replaced cases where 0 was passed as Qt::KeyboardModifiers
with Qt::NoModifier (clang-tidy replaced them with nullptr, which
waas wrong, so it was just as well to make the tests more readable
rather than to revert those lines).
Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The functions are marked Q_REQUIRED_RESULT, so they give compilation warnings
when not handling the bool return value. Failing the test early at an unexpected
event is also better behavior anyway.
Task-number: QTBUG-66559
Change-Id: I6c4db29379ec01528208c3e4ee54346b4230616c
Reviewed-by: Sami Nurmenniemi <sami.nurmenniemi@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2e7d4ecdc5 caused the regression.
To fix the regression I try accessing the signal name first
and if it is not a function try accessing the handler name.
Comes with a unit test to test both cases.
Change-Id: I3897f344df9c6219636c70259eed503d9b76f09e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Lucie Gérard
Mitch Curtis
Andrei Golubev
Shawn Rutledge
Kari Oikarinen
Albert Astals Cid