| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Task-number: QTBUG-10654
Reviewed-by: Thierry Bastian
|
|\
| |
| |
| |
| |
| | |
Conflicts:
qmake/generators/symbian/initprojectdeploy_symbian.cpp
qmake/generators/symbian/symmake_abld.h
|
| |
| |
| |
| |
| |
| | |
Everywhere we have a qWait(duration) followed by a QCOMPARE, there was
the risk that it fails because of the test machine being overloaded.
So I changed them to QTRY_COMPARE.
|
|/
|
|
| |
Using duration + 100 ms is apparently not sufficient.
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QAbstractAnimation:
currentTime returns the "complete" current time
currentLoopTime() returns the time inside the current loop
add setPaused(bool) for consistency with QTimeLine
stateChanged: newState passed as first paramater (before oldState)
for consistency with the reset of Qt
QAnimationGroup:
rename clearAnimations to clear
rename insertAnimationAt to insertAnimation
rename takeAnimationAt to takeAnimation
QSequentialAnimationGroup:
rename insertPauseAt to insertPause
|
|
|
|
|
| |
We now wait for the animation duration + 100 (instead of 50).
It makes tests more reliable on windows (and probably embedded)
|
|
|
|
|
| |
Timers on windows are not accurate enough to "only" wait for the
animation duration + 50.
|
| |
|
|
|
|
| |
Reviewed-by: Leo
|
| |
|
| |
|
|
|
|
| |
also improved the autotests
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
| |
updateCurrentTime
That deletion removed the respective animation from the list of running
animations being processed, but not from the copy of the list introduced in
48489988521b818bda8d76e60cb272508e91b490, thus we had a dangling pointer.
Reviewed-by: thierry
|
|
|
|
|
|
|
|
| |
The problem was we were iterating over the list of running animations.
And when calling setCurrentTime(<duration>) on one of them they just
unregister themselves from the timer and we would miss some of them.
Reviewed-by: leo
|
|
|
|
| |
Reviewed-by: ogoffart
|
|
|
|
|
|
| |
It is now possible to set a start value and no end value and starting
the animation will pick the default end value from the current value
of the property that's being animated.
|
|
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
| |
The problem is that when restarting, the time is at the end. So the
current value changes to the end value instead of the initial value.
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
| |
the same type as the property
For example, if you set a start value of 0 (integer) for a qreal
animation, it would not work.
Reviewed-by: janarve
|
|
|
|
|
|
|
| |
The current value was udpated on setKeyValueAt, but not on setKeyValues
and this was leading to a semantic inconsistency.
Reviewed-by: janarve
|
|
|
|
|
|
|
| |
If we have less than 2 key values, we should neither try to interpolate
nor set the current value.
Reviewed-by: janarve
|
| |
|
|
|
|
|
|
| |
of the object
Task-number: 251763
|
|
|
|
|
|
|
| |
The default start value is updated when the animation changes from
Stopped to Running state.
Reviewed-by: Jan-Arve
|
|
|
|
|
|
|
|
| |
When the start value is not explicitly defined, the property animation
will set the default start to be the current property value when updating
the animation's state to Running.
Reviewed-by: Jan-Arve
|
| |
|
|
|