Most of the time, you want to treat a system like Qt as "an
event-driven system." The main loop of the program processes a queue of events ... very quickly, but one-at-a-time. The design of the system is such that you can define your own, "custom," events, and have them be dispatched just like those which are built-in to Qt.
Threads, in such a context, are usually more trouble than they're worth because the concept really doesn't fit well within the model established by Qt. In fact, it rather defeats the purpose. Threads, when inappropriately used, often spend inordinate amounts of time fooling around with semaphores and other mutual-exclusion objects, whereas "modern CPUs are
so damn fast that" a clean, well-implemented, event design can accomplish the same work (often) even faster.
You need to be aware of how both mechanisms work, of course. But most of all, spend serious time in the Qt documentation "really getting to know how it works." In other words, "what were the designers thinking
when they wrote this thing, and why?" As they say, "figure out what the Romans are doing."
