Review Request 120160: KMessageWidget: fix handling of rapid succession of animatedHide+animatedShow calls

Fabio D'Urso fabiodurso at hotmail.it
Thu Sep 18 10:40:44 UTC 2014



> On Sept. 13, 2014, 3:20 p.m., Milian Wolff wrote:
> > autotests/kmessagewidgetautotest.cpp, line 115
> > <https://git.reviewboard.kde.org/r/120160/diff/1/?file=311761#file311761line115>
> >
> >     Couldn't this actually check that no animation is running at all now? We triggered the hide directly after the show, without going into the eventloop inbetween. I'd expect no animation to be triggered at all.
> >     
> >     generally, I'd urge you to split this test function into smaller ones and give each test a good name so that its clear what you check.
> >     
> >     Then also add a case for the case you try to test here, but don't actually (as far as I can see). Namely:
> >     
> >         w.animatedShow();
> >         QTest::qWait(10);
> >         QVERIFY(w.isShowAnimationRunning());
> >         w.animatedHide();
> >         QVERIFY(w.isHideAnimationRunning());
> >         QTest::qWait(10);
> >         QVERIFY(!w.isHideAnimationRunning());
> >         QVERIFY(!w.isVisible());
> >     
> >     and similar for the animatedShow/Hide when it is shown already.

"Couldn't this actually check that no animation is running at all now?" -> Well, with the current implementation that would not be true because, as far as I can see, the QTimeLine stays in running state (see updated test in patch v2). I don't know QTimeLine internals, but I guess it needs to process some events before it can notice that there's actually nothing to do.

In the new version of the patch, I've simplified the `while (w.isShowAnimationRunning() || w.isHideAnimationRunning())` so that it only checks one condition instead of two. Previously I had put these two checks because unpatched KMessageWidget runs the wrong animation and I wanted to wait for *any* animation to finish before checking the outcome, but in the new version I've added a `QVERIFY(w.isHideAnimationRunning())` before the loop, which guarantees that the correct animation is running.

About the splitting, I'm using the widget height to test if the message is fully shown or hidden (see `shownHeight` and `hiddenHeight` variables). These values are first obtained through simple single `animatedShow`/`animatedHide` calls in the first part of the test, and then used in the second part of the test as reference height. So, if I split the test into smaller pieces, I would not have this data anymore and I'd have to drop the height checks. So we have two options: one big test that checks the height, several small tests that don't check the height. The height check is not strictly necessary, I've added it for extra safety, what do you think?

About your last comment, actually I am testing if `animatedShow` immediatly followed by `animatedHide` works (and vice versa). But I think I see your point, so I've added a `QVERIFY(w.isShowAnimationRunning())` after every `w.animatedShow()` and a `QVERIFY(w.isHideAnimationRunning())` after every `w.animatedHide()`, what do you think, is it better now?
On the other hand there's no need to insert qWait between `animatedShow` and `animatedHide`, because it would still test the same code paths, at least given the current implementation.

Also, I'm not a huge fan of the fixed timining you're proposing, because it would depend on the first `QTest::qWait(10)` to sleep no longer than the second one, which is something the OS can't actually guarantee.


- Fabio


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120160/#review66411
-----------------------------------------------------------


On Sept. 18, 2014, 10:40 a.m., Fabio D'Urso wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120160/
> -----------------------------------------------------------
> 
> (Updated Sept. 18, 2014, 10:40 a.m.)
> 
> 
> Review request for KDE Frameworks, Christoph Feck and Aurélien Gâteau.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> -------
> 
> Hi, I've found that if you call animatedShow() immediatly after animatedHide(), without waiting for the hide animation to finish first, the hide animation goes on and, in the end, the message widget becomes hidden.
> 
> The attached patch adds checks in animatedShow and animatedHide so that, if an opposite animation is currently running, they just reverse it.
> 
> 
> Diffs
> -----
> 
>   autotests/kmessagewidgetautotest.h 062e2b3 
>   autotests/kmessagewidgetautotest.cpp f46bab0 
>   src/kmessagewidget.cpp bc7ba32 
>   tests/kmessagewidgettest.cpp f621b5a 
> 
> Diff: https://git.reviewboard.kde.org/r/120160/diff/
> 
> 
> Testing
> -------
> 
> I've added buttons to invoke animatedShow and animatedHide in tests/kmessagewidget.cpp and used them to test the behavior.
> 
> I've also added an autotest that checks the final height and isVisible() value, both after single animatedShow/animatedHide calls and after animatedShow+animatedHide and animatedHide+animatedShow.
> 
> 
> Thanks,
> 
> Fabio D'Urso
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140918/c2ff00b1/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list