Some properties of one of the member animations in a group
animation can be changed after the group animation initialized.
1. If the group animation is already proceeding, they will
affect the next loop.
2. If the group animation started but does not proceed, they
will affect the current loop
Fixes: QTBUG-110589
Fixes: QTBUG-61282
Fixes: QTBUG-95840
Pick-to: 6.6 6.5
Change-Id: I018105bdd75dd5bd7c24e9126853cd79c8f0123b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8:
auto QtContainerClass = anyOf(
expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o),
expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o));
makeRule(cxxMemberCallExpr(on(QtContainerClass),
callee(cxxMethodDecl(hasAnyName({"count", "length"),
parameterCountIs(0))))),
changeTo(cat(access(o, cat("size"), "()"))),
cat("use 'size()' instead of 'count()/length()'"))
a.k.a qt-port-to-std-compatible-api with config Scope: 'Container',
with the extended set of container classes recognized.
Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Animate less frames and switch to QTRY_VERIFY so animation always reaches
the final frame on all CI platforms. Test that frame >= 3 as in some
platforms one more frame might arrive after pausing.
Pick-to: 6.4
Task-number: QTBUG-104107
Change-Id: I76e0d0fea2566fb7fb4d4e1c46e58121d3751902
Reviewed-by: Mitch Curtis <mitch.curtis@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>
FrameAnimation is a helper synchronized to animation frame updates
which can be used for custom animations and similar needs.
Compared to QML Timer element, it doesn't allow setting the interval
or repeat properties. Instead, it is triggered on animation updates
and provides useful properties like frame number and frameTime &
smoothFrameTime for fps-independent animation steps. Also it is
directly synchronized with QAbstractAnimationJob instead of going
though an extra Qt event loop like the QML Timer.
Contains autotest and manual test.
Task-number: QTBUG-102641
Change-Id: I5c72992462aba651b6fe8f2846baac3346799c56
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Animations with multiple loops without an explicitly set 'from'
value were trying to use the last value from the previous loop
as the new starting value for the next loop.
This is not correct for several reasons:
- when we have multiple loops, it's not guaranteed that the last value
of the previous loop is actually the 'to' value. In practice it is
a bit smaller.
- even if it was the expected 'to' value, the next loop would have been
executed in the range [to; to] - so nothing would have happened.
The code in bugreport for the related issue tries to implement a
binding:
NumberAnimaton {
// note that the 'from' property is not defined here
to: from + 360
loops: Animation.Infinite
}
But I believe such binding does not work in practice, because the 'from'
*property* is not actually updated at each loop.
So the most reasonable approach for the animations with multiple loops
is to use their initial 'from' value, and do not update it while
looping.
Fixes: QTBUG-84375
Pick-to: 6.3 6.2
Change-Id: I550873887bf8a328fe4eda9b0e8e058f921124b1
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The main motivation for this is convenience, but it also allows controls
to respond to resizing for items that have animations without resorting
to JavaScript to call restart().
[ChangeLog][QtQuick] It is now possible to set the from, to, duration,
and easing properties of a top-level animation while it is running.
The animation will take the changes into account on the next loop.
Change-Id: I2f560ee713666e67b7162d95ff28621fcf3b2545
Fixes: QTBUG-38932
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
grabWindow is now implemented for the offscreen plugin, so a large
number of tests relying on that functionality don't need to be skipped
any longer.
Change-Id: I85bfc9e4b327389055041b6187a54f88d9cf81d2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Amends 4b125a5bfd, which reset the pointer
in registered jobs when the timer was destroyed. However, if a job is
unregistered explicitly before the timer is destroyed, then the job's
m_timer pointer might still be a dangling pointer, resulting in a crash
when the job is reactivated later.
So clear the job's pointer to QQmlAnimationTimer whenever it is
unregistered from the timer. Since a running job can then have a nullptr
timer, only assert in the job's destructor if the timer is not nullptr.
Introduce a test case that reliably crashes without the fix. The test
is added to the QQuickAnimation test as it uses a Qt Quick UI.
Fixes: QTBUG-98248
Pick-to: 6.2 6.2.2 5.15
Change-Id: Ief991900c50aefd480d9c79e83324968102ca29c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
QColor operates on floats, not qreal or double, so explicitly use float
literals in test code.
Pick-to: 6.1
Change-Id: I6f0cb56e861b4812fc79ce67ade9abe3ee9dfddc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
This way it's fundamentally impossible to add the same animation job to
two different group jobs. The pointers are not exposed anymore and no
one can re-order the jobs.
Task-number: QTBUG-90401
Change-Id: Iebff4b64960c853915dd32714acd144fc5cdc00d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
AnimatorProxyJob would not forward loopCount to the controlled job causing
the sequential or parallel animation to go infinitely after attempt to stop
Task-number: QTBUG-82890
Pick-to: 5.15
Change-Id: I6a1ca787f06789064e05407bbe9ae5e5861f24d5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We don't need to register the Type enum for both QtQml and QtQuick.
QtQml is enough. Removing this makes the whole manual value type
registration obsolete. Furthermore, we want QEasingCurve as QML_FOREIGN
as we have several classes with properties of that type. To keep it nice
and tidy, we make the uppercase-named enum holder class a separate type.
Unfortunately, the Type enums differ in one entry:
QEasingCurve::BezierSpline is called Easing.Bezier in QML. Therefore, we
need to keep the custom enum around. We can change all users in
qtdeclarative to use the name from QEasingCurve, though.
Change-Id: Ibbc78d8bbf8938e2a8722f8c09833a0c73394c3d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When using OpacityAnimator, an opacity node will be created and inserted into
nodes tree to perform opacity animation. However, since the default value of
opacity node is 1, the opacity animation will start from 1 even if we set
it from 0 to 1.
Fixes this issue by updating the value of opacity just after creating a new
opacity node.
Fixes: QTBUG-79199
Change-Id: I2e462f0c56892fda040836ffde6685145769e60c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The order for non-zero-duration animations are:
* started()
* runningChanged(true)
* stopped()
* runningChanged(false)
* finished()
This patch tries to ensure that zero-duration animations have the same signal
emission order.
The problem was that when setRunning(true) was called on zero-duration
animation, it would call itself (setRunning(false)) lower in the call stack in
order to immediately stop again. This had the implication that we could emit
stopped() even before started() was emitted (since the recursive call to
setRunning(false) would actually complete before the ancestor stack frame
setRunning(true) was completed)
To fix this we emit started() *before* we call start() on the animationInstance.
There is still a bug in that runningChanged(true) is still not emitted for a
zero-duration animation, but this patch should improve the current behavior in
the sense that stopped() is not emitted _before_ started().
Task-number: QTBUG-48193
Change-Id: Ic2bc85e648e6746f6a058e2e9136515e7fdb6192
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The cause was that fast flicking kicked items in and out of viewport,
while in transition, they would abruptly having tracking data structure
, i.e. releasePendingTransition of QQuickItemViewPrivate, got iterator
invalidated. This also helps to resolve QTBUG-44308.
Fixes: QTBUG-76433
Fixes: QTBUG-44308
Change-Id: If14533d3f6b1acd7b6ca0c5c723347c0cb3f54dc
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
The root cause was that the QAbstractAnimationJob::finished() might delegate its
destruction to change.listener->animationFinished(this), and the original author
was aware of that and provided a RETURN_IF_DELETE macro to return early if itself
got deleted. In the bug's case, change.listener->animationFinished(this)
dispatched to QQuickItemViewPrivate::animationFinished() which called
QQuickItemViewPrivate::release() and deleted the QAbstractAnimationJob object
itself in the end.
However, any objects derived from QAbstractAnimationJob, or holding a pointer
to a QAbstractAnimationJob, may potentially fall into the code path calling
QAbstractAnimationJob::finished(). Any QAnimationJobChangeListener that directly
or indirectly deletes QAbstractAnimationJob should be very suspicious to this
kind of "heap-use-after-free" bug. Should ensure that the QAbstractAnimationJob
won't be referenced after deletion.
In the bug's case, within the code path triggered by ListView displacement
animation, the other affected classes by QAbstractAnimationJob are:
QQuickItemViewFxItem, QQuickItemViewTransitionableItem, QQuickTransitionManager.
To fix this, a new SelfDeletable class is factored out to simplify the self-deletion
test logic. Any affected classes are made to have a public member m_selfDeletable.
Any code paths that finally reach QAbstractAnimationJob::finished() are
wrapped with related util macro.
Change-Id: Idd33fc3f2d529fd7d8bb088c329101b1e70dd6c0
Task-number: QTBUG-44308
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The model types are not part of the core QML runtime and should only be
loaded if you explicitly import them. We cannot enforce that in Qt5 as
some of them are available from the QtQml import, but we can change it
in Qt6.
Change-Id: I1e49e84d748e352537ec2d4af901c034c91d038f
Reviewed-by: Erik Verbruggen <erik.verbruggen@me.com>
When a running transition does not finish of natural causes (reached
the end state due to e.g. the timer finishing), it can happen that it
will never be marked as finished. Specifically, when an transition is
running (e.g. an add animation for a ListView), and that transition is
replaced by another transition (a displace transition, because another
item got added to the ListView before the add transition was finished),
the first animation was never marked as stopped. The effect was that
the running property would stay "true" for forever.
Task-number: QTBUG-38099
Change-Id: Icbcc732f787ff23c72d843f1ecaa86a2cc9c75ec
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This reverts commit cf0b965aaa because it
causes crashes in qtquickcontrols tst_extras.
Change-Id: I3809f2da84cf24b990b017a44837c02fc6c776d1
Task-number: QTBUG-69497
Task-number: QTBUG-38099
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When a running transition does not finish of natural causes (reached
the end state due to e.g. the timer finishing), it can happen that it
will never be marked as finished. Specifically, when an transition is
running (e.g. an add animation for a ListView), and that transition is
replaced by another transition (a displace transition, because another
item got added to the ListView before the add transition was finished),
the first animation was never marked as stopped. The effect was that
the running property would stay "true" for forever.
Task-number: QTBUG-38099
Change-Id: Id7d7053cb2fc1912127d9f5e71f27eb984ba7435
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Currently, Animation has a stopped() signal. This is executed even if
the animation is stopped manually. To react to an animation finishing
naturally, you currently have to do the following:
onRunningChanged: if (!running) doStuff()
This patch adds a dedicated signal:
onFinished: doStuff()
[ChangeLog][QtQuick][Animation] Added finished() signal to
Animation as a convenient way to react to an animation finishing
naturally.
Change-Id: I8765d3e8e2b7bf7ef66a6acb69feafb43e9619d3
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
Otherwise we may get called back when the window's scene graph is ready,
but we don't have a controller anymore then. This leads to a crash.
Change-Id: I8075619e1fd3c69ca0f7d0b1d72952b8cc5040f8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Both QQuickPathLine and QQuickPathSvg inherit QQuickCurve class which
has “x” and “y” properties that return qreal type, but internally they
are stored as QQmlNullableValue<qreal>. At the same time, if any of them
is not specified explicitly, its getter returns 0.
QQuickPath processes QQuickPath%Type% objects and produces a
QPainterPath which later used by QQuickPathAnimation.
QQuickPathAnimation only created a QAbstractAnimationJob if
QQuickPath::hasEnd returned true, and hasEnd returned true only if both
“x” and “y” were specified explicitly.
All that in conjunction led to the situation when if you had either
- a PathLine with unspecified “x” or “y”; or
- a PathSvg
which was the last (or the only) path element in your Path,
PathAnimation would not start.
This patch removes hasEnd check, it should be safe to do because
QPainterPath is always valid anyway due to the fact QQuickCurve::x()
and QQuickCurve::y() return 0 if they have not been not explicitly set.
Task-number: QTBUG-57666
Change-Id: Id320aaeb5aff0964d6493b7b80d5d9a7d36acce8
Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I04760a0801837cfc516d1c7c02d4f503f6bb70b6
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
When at least one default property of a target object is considered
valid by an animation, we don't need to warn about other default
properties that weren't found.
Change-Id: I648f17a55fdfcbed2b4c7e94d88206c3dc3d1a32
Task-number: QTBUG-22141
Reviewed-by: Michael Brasser <michael.brasser@live.com>
This avoids ending up with invalid pointers when under some circumstances the
target (which is not owned by the QQuickAnimatorJob) is destroyed between the
time the QQuickAnimatorJob is created and the time it is initialized. This is
the case when the target of an Animator is the item loaded by a Loader and
that the animator is started just before setting the Loader to inactive.
Also added an auto test for that special case.
Task-number: QTBUG-49634
Change-Id: Iab9bfe76d13755ba735432c6f97bde175d308814
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
- Replace Q[TRY]_VERIFY(pointer == 0) by Q[TRY]_VERIFY(!pointer).
- Replace Q[TRY]_VERIFY(smartPointer == 0) by
Q[TRY]_VERIFY(smartPointer.isNull()).
- Replace Q[TRY]_VERIFY(a == b) by Q[TRY]_COMPARE(a, b) and
add casts where necessary. The values will then be logged
should a test fail.
Change-Id: Ib9f4c2486af23c47990be4b9e004b965de226dcc
Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
Preparing the replacement of Q[TRY]_VERIFY(a == b) by
Q[TRY]_COMPARE(a, b) for non-boolean types.
Change-Id: I8a4e44a2b4e20a9c8b811799e3932c8ce1a2cbbb
Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9
Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
As we usually don't get realtime guarantees we cannot rely on exact
sleep times. This change relaxes our expactations in that regard.
Task-number: QTBUG-29062
Change-Id: I54dfb7a28d6bb46479aedb9f943f5ff4db2df701
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
These tests typically fail in the CI.
Task-number: QTBUG-36290
Change-Id: I36a19c2914932d4f70c1df24e1c5ad4a3d0e2795
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@digia.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
Check if pointer to QQuickAbstractAnimation for which we are setting
group is valid.
Task-number: QTBUG-34851
Change-Id: Iecb549f080804fd9489f884911fa51892def05a5
Reviewed-by: Lars Knoll <lars.knoll@digia.com>