Quote Originally Posted by burn2themax
The question is, what is the correct way to implement such a dynamic widget/thread relationship? I don't like to have a pool of signals (like dataReady1, dataReady2, ...) hardcoded in the app and then assigned to a dedicated widget. This is not dynamic, since the max number of signals is given at compile-time. The other possibility to emit the signal "dataReady" to all widgets and let the widget decide, whether the data is for itself isn't a better way either (signalling overhead).
There are only two possible ways to do this, one is that the thread has a reference (pointer or whatever) to each data-widget and makes a call (function call, signal emit or whatever) to the correct widget. Or the thread will have to broadcast and it's up to each widget to see if the data is relevant or not. Both approaches have their advantages, the second for example allows for adding new widgets which displays some custom set of results without having to modify the thread.

You say you are affraid of signaling overhead, which I take as a sign that this is performance critical (since signaling overhead is quite low), then perhaps you should implement some king of asynchronic messaging, the thread sends out messages which are placed in a buffer which is read by the widgets.

Another approach (with no broadcasting) would be to use a collection of function-pointers. One pointer to each widget, the thread could then store them in some kind of associative container (a map) and based on the kind of information find the right pointer in the collection and perform the call.