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>
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>
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>
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>
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>
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>
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>
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>
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>
Rename completed to stopped (as it is not only emitted
on completion). Ensure that the started and stopped signals
are emitted at the right times. Document the signals.
Task-number: QTBUG-14968
Change-Id: Icd3babcef2c9e544476592a26e6b9e58a21ebe95
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
When set progress value out of [0,1], path animation and
path interpulator should make sure the value be modified
in the valid value range, otherwise the QQuickPath::backwardsPointAt()
will crash.
Task-number: QTBUG-24308
Change-Id: Icd6e9165c9f844ddb8ec84c229eac4db5246a749
Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
Symbols beginning with QDeclarative are already exported
by the quick1 module.
Users can apply the bin/rename-qtdeclarative-symbols.sh
script to modify client code using the previous names of the
renamed symbols.
Task-number: QTBUG-23737
Change-Id: Ifaa482663767634931e8711a8e9bf6e404859e66
Reviewed-by: Martin Jones <martin.jones@nokia.com>