Some more info: After adding a debug line for "event->timestamp()" as well, it turns out on my machine (this is most likely not only happening on my machine though) the timestamps for mouse events are always 0 (probably just not supported by the middleware or something similar). See this log for both a successful and failing run, the events timestamps are always 0 http://pastebin.ubuntu.com/15196543/
When timestamps are 0, QQuickFlickable uses a QElapsedTimer to check how many msecs passed since the press event. Proof: https://github.com/qtproject/qtdeclarative/blob/5.4/src/quick/items/qquickflickable.cpp#L916 On my machine (just like it should be on any other Linux platform) QElapsedTimer is using the monotonic clock (checked with another debug line in qquickflickable.cpp). So, what happens, is probably that the Press -> move -> move -> move -> move -> Release events generated by the flick() function are some times all delivered in the same batch. In that case, QElapsedTimer::elapsed() always returns 0, and that causes the event to be ignored by the velocity computation logic. Proof: https://github.com/qtproject/qtdeclarative/blob/5.4/src/quick/items/qquickflickable.cpp#L1096 As a consequence, when the mouse release happens, the flick is not started because velocity is believed to be 0. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1549256 Title: UbuntuTestCase's flick() function is unreliable, does not always flick a Flickable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1549256/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
