I have a rather tricky data adapter I'm trying to design for an applications user settings view...

The Model / View architecture


Config File -> Source Model -> Group Filter -> Setting Filter -> Adapter -> Setting View


Config File


Contains all settings (listed in their corresponding groups).
A group with a multi-valued setting may appear as:


[Library Group]
Libraries = LibA
Libraries = LibB
Libraries = LibC


Setting Model


Directly represents the settings as they are shown in the config file, with each record representing one setting's value.


Group Filter


Filters the source model settings by each setting's group.


Setting Filter


Filters the group filter's results by the setting name. In the example above, the group filter (for "Library Group") and the setting filter ("Libraries") would both return three records.


Adapter


Manages the records returned by the setting filter, converting them into meaningful data to be displayed in the setting view.


Setting View


Widgets used to manage / represent the setting. In the example above, there are only four available values, LibA, LibB, LibC, and LibD. A checkbox view of the setting may look like:


[X} LibA
[X] LibB
[X] LibC
[ ] LibD


Since a checkbox only understands "true / false", I need to convert the source model values into corresponding true/false values. (I could use bitflags here and dodge the whole issue, but it defeats the purpose of the example).
Anyway, the data adapter step provides that conversion between the values available in the setting filter and the widgets.


The Problem


I've pulled it off without using the QDataWidgetMapper or any means that makes the view aware of changes in the model.

I need to do that somehow.

QDataWidgetMapper seems the most reasonable way to accomplish that, but doing so means I need to create a submodel which contains a fixed row for each checkbox in the view.

So if the source model adds / deletes a value (apart from a user interaction with the view), is it just a matter of trapping the layoutChanged() signal from the source model, making the corresponding updates in the submodel, and signalling dataChanged() for the sake of the QDataWidgetMappers attached to the view widgets?

I ask because I have to create a framework that manages different view types, which will require various custom adapters and I want to make sure my atomic structure is sufficient to manage that.