Tricky model/view data adapter design...

[graffy]

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.

[wysota]

Hmm... what exactly is the problem? Your "The Problem" section specifies what you didn't do and not what the problem is

If the problem is making the view aware of the changes in the model then it is done by making the model emit proper signals (dataChanged, rowsInserted, rowsRemoved, etc.) when its contents change. Then the next layer can make use of those signals to emit its own, etc.