Short animation of a label: thread or better?

[myoan]

Hi all,

I'm looking for a way to get the user's attention on a label esthetically, for instance by making it changing from a color to another during 2 seconds "like stackoverflow does with the background of a linked message for instance":http://stackoverflow.com/a/2340316

To avoid the whole GUI to freeze during 2 seconds I intended to open a dedicated thread changing the background color from orange to grey by step of 50ms for instance.

Is there a better way than threads to achieve this precise goal?

How would you declare and create it (single thread, table of thead, initialized when the window opens, created on-the-fly as needed...)? When would you join it? I may have potentially an infinity of labels to animate but only one at once, so I wanted to declare only one animation thread, and wait its termination each time before joining it and creating the next one (listening to a variable or something to stop animation before the 2 seconds if a new animating is pending)

Many thanks

PS: Even if you suggest something better than threads for this kind of animation, I'm interested in your answers concerning when joining such threads for other purposes

[qxoz]

For such simple animation you can use QTimer.
For complex animations you can use "Animation Framework":http://qt-project.org/doc/qt-5/animation-overview.html

[MuldeR]

Since you must not access GUI widgets directly from a background thread, you would have to send queued signals from the background thread the your dialog, that lives and the main thread, and modify/update the widget from there. But then your are essentially emulating a QTimer. So I would use a QTimer right away. Unless your "animation" requires computations that take a long time - which might be better done in a separate thread.

[myoan]

Thank you.

What benefits would have queued signals instead of creating and calling a method dialog->animate(...)?

Concerning these thread questions I figured out I could use std::asynch instead.

[MuldeR]

If you access a GUI widget directly from a "background" thread, i.e. a thread that is not the application's "main" thread, you are getting undefined behavior! That's because GUI widgets generally are not thread safe. So if you want to update a GUI widget from a background thread, you should do this by sending a (queued) signal from the "background" thread to your "main" thread whenever an update is required. The actual update of the GUI widget will be perform in the context of the "main" thread. The benefit: Application won't crash ;-)

[myoan]

Ho yes the animation() could be called from different threads. In practice only one thread will trigger the animation but in case... ok thanks :)