Updating a View when Model Changes Externally

[wysota]

I somehow missed this post earlier...

I assumed that it is a good idea to gather all events (delete, edit, copy etc) in a central class (something like a controller class, or mediator) and then propagate the events to the model.

The model is your central/controller class. Just make everything go through the model emitting proper signals. You can extend the model with your own methods - as long as you'll be emitting signals, everything will be fine. That's what the link I provided in the previous post explains.

[ghorwin]

Hi All,

it appears to me that this kind of problem actually occurs quite often in real-world problems. For example, in our code we have quite a large data model (thermal simulation model for a whole building including detailed geometry and appliances) which is built-up hierarchically. In our user interface, we have different views that only show certain parts of the model, sometimes in table views and sometimes in tree views.

To fill the different table and tree views with data, we have several implementations of QAbstractItemModel and QAbstractTableModel which source the data directly from our object hierarchy, this from the model's point of view the data is external.

Now often we have the problem that part of the data in our object hierarchy changes, for example through interaction with one model. Other models that show the same data in a different representation do not know that the external source data has changed and we have the same problem as mentioned in the thread here, that we need to tell each model implementation which part of the data has changed.

This is difficult to do properly, so here are some options:

1. Use brute force and tell every model to reset(). This is bad because selection and item states are lost. It works ok, when the complete object hierarchy is newly populated (e.g. after loading the project data from file), but for minor changes it is overkill.
2. Use each model's data() function to determine which model indices have changed. This is slow and doesn't work well in many cases when type conversions are done inside the data() function.
3. Let each model cache the data it shows so that the models can always check for differences between the model's data representation and the source data and emit the dataChanged() signal accordingly. This is probably the best way, however, it has quite a memory overhead and is sometimes tricky to implement for non-trivial models.

Maybe you could comment on these and provide alternatives if possible?

[wysota]

You should have one model inheriting QAbstractItemModel and all your "submodels" should just be proxies over the base model. If needed, you can add your own methods (and signals) to those classes, just don't separate the models - otherwise you will immediately run into synchronization problems. And make sure proper signals from QAbstractItemModel API are always emitted from the custom methods where appropriate.