Although it turns out that I can't flick the list, because the items require some custom mouse move handling ... which reduces it to a non-interactive PathView. So, solved I guess! Thanks for pointing out the Tumbler though, and I hope my examples prove to be useful to others.
Set explicitly all names of properties because this is what you want. In some cases you might want not to animate prop1.
And this is default reaction of the engine: make change without transition (this is about performance).
In this Sprite after finish in 1/10 times Sprite named blink will be rendered and in 9/10 times this Sprite will be repeated. For more details aboud sequence you can read the example that I posted in past.
What exactly do you mean with blinking?
If you have set a min and a max value, there is no blinking animation. It just shows the currently set value.
You may need to look at documentation again: http://doc.qt.io/qt-4.8/qprogressbar.html
@Buttink The attached properties are not always directly accessible by the children. It is documented here.
A common error is to assume that attached properties and signal handlers are directly accessible from the children of the object to which these attributes have been attached. This is not the case. The instance of the attaching type is only attached to specific objects, not to the object and all of its children.
It looks like there might be an easier mechanism to do this kind of thing with in the future.
Rather than writing my own MenuBar from scratch, the Qt team have implemented styling support for most of their components. Whilst i haven't tried this yet (I'm stuck on a different part of my project at the moment), MenuBar Style should be perfect for what I was originally trying to acheive, by writing custom delegates, with the appropriate behaviours attached to their properties.
I'm experimenting a bit with QML as we speak, but classically using standard Qt4/Qt5 you would have an EventTimer() (specified by some msec timer update) and a Paint() function that you can override in your Draw class doing the screen update. (Actually another approach is possible as well)
But basically, inside the Paint() update you would do the drawing & animation needed. QML may have something similar in updatePaintNode().
Hope that helps,
Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.