Is it too much to ask for a decent example? In this case, the user is still doing just 1 task, with the addition of a cancel and progress button.
In reality, if calculation code reports progress and is cancellable, its probably easily performed synchronously, with a cancel-check at each progress update. When cancelled, the main thread would still have to join the threaded calculation's thread (or at least wait for it to cancel), so there is almost zero benefit to threading this example.
You've taken a trivial example that would work perfectly as a single-threaded task and popped it in a thread... I'd like to see an example that would be difficult to do in a single threaded world. Even the web responses isn't a great example, because theres always the ol' select() pattern that was once commonplace.
Can you post an example with some meat? Eg, doing two backgrounded tasks that work together would be a good start.
Even two independent backgrounded tasks can be difficult in a single-threaded context as it can be tricky to return control to the first task.
Eg faking backgrounding by calling QT's qApp->processEvents() regularly - this doesn't return control to the first task until the second task is done. For that to work, you have to break the computation into callable chunks and schedule the chunks with postEvent or a QTimer.
If that sort of thing was discussed, it might help educate those who don't fully understand why multithreading is so powerful.