Hm, the whole point is that QMyObjects live in a different thread. However they are not thread-safe. That is done intentionally because mutexing them would cause a lot of overhead. This means the UI cannot call myobject->property1(), because it isnt safe (it could change while be called).
Now background threads might change the data in one of those QMyObjects. This Object will have to emit a signal that it has changed state and what to, so that the front-end (in this case the UI) knows whats going on and specific things change (i.e. the treeview representation of the object).
Connecting all these signals to the Model instead of the item will not reduce the number of connections, it will only create another step between "dataChanged" and " visual represention changed".
Now I am aware that 20000 qobjects as list items are a little more expensive than simple "non-q"-objects, but considering that I need these specific signals from the QMyObjects in other places, I think it a fair trade-off.
It actually works rather well with the QTreeWidget, its just that that wont let me do proper filtering
Also a Model might be handy, when implemting a second view for doing content-based searches on QMyObjects...
Bookmarks