@fcarney yeah, probably would have to just test and measure the performance, which is probably quite a bit of work with unsure result and sadly, I don't have unlimited time..
Meanwhile, I've came up with different approach and even tested it a little and it seems to be working. Not sure how viable it is or what pitfalls it might have though.
Basically, I'd change my models into models of QObjects with Q_PROPERTY for every role. Model would function as normal but would have extra functionality - it would be possible to register another QObject of same class as a mirror (each xChanged property signal from source item would be connected to setX signal of the mirror). This mirror QObject would exist in QML and its properties could be used in the same way as model roles.
Repeater {
model: playerModel
delegate: Item {
Label {
text: "Player name: " + nameRole
}
PlaylistMirror {
id: playlist
uuid: playlistUuidRole
}
Label {
text: "Playlist name: " + playlist.name
}
}
This mirror object would register itself to the model whenever its uuid property changed. Something like this (with checks ofc):
void register(QUuid uuid, Playlist *mirror) {
Playlist * source = find(uuid);
connect(source, &Playlist::nameChanged, mirror, &Playlist::setName);
mirror->setName(source->name()); // initial sync
// same for all roles
}
It should be safe - if the source object got destroyed by mistake, it would simply stop updating the mirror instead of crashing that would happen if I just got raw pointer from the model. There would have to be some logic for cleaning (if mirror changed the uuid, it would have to disconnect and connect again; if source was deleted, mirror should be cleaned) but otherwise, it seems like decent solution.
The performance hit of generating xChanged signals without any receiver should be negligible and there is no need for any extra models or filtering. Higher memory usage is non-issue.
Here's diagram for better illustration:
[image: 7384b685-a006-435b-be61-fa8afecc899d.png]
What do you think?
