On 4/22/19, 10:10 AM, "Marc Van Daele" <marc.van.dael...@gmail.com> wrote:
• If I don't need signals and slots on my Person class, I should use a POD.
PROP(QList<Person*> persons) will be supported but whenever something changes
in the list or any property of any item in it, the complete list has to be
resent (there is only a single personsChanged signal)
In general, I like PODs for simple data collections that make sense to go
together, but don't need signals and slots. I can't tell if "Person" fits
that, but your description of the implications of using PODs (or a QList of
PODs) is correct.
• If I do need signals and slot on my Person class, Person should be a
rep-class (nested inside Household)
o I can create a MODEL(persons) [can you give a pointer of this syntax?
I couldn't find much info on MODEL].
The CLASS and MODEL keywords are distinct from each other. MODEL -->
QAbstractItemModel (QAIM), CLASS --> QObject.
MODEL example:
https://code.qt.io/cgit/qt/qtremoteobjects.git/tree/tests/auto/modelreplica
CLASS example:
https://code.qt.io/cgit/qt/qtremoteobjects.git/tree/tests/auto/subclassreplica
• This will behave as if the model was local to the client. Slots can be
called on the items in the model, signals of the model and the individual items
in the mode can be received.
• Is it correct to say that the HouseholdReplica contains a model of
PersonReplica (pointers) and the HouseholdSource contains a model of
PersonSource (pointers) ?
• Can both the client and the server add rows (new Persons) to the model?
o Can I also create a PROP(QList<Person*> persons)?
• Is it correct to say that the HouseholdReplica contains a QList of
PersonReplica pointers?
• Are the PersonReplica's automatically linked to the corresponding
PersonSources? Or should I somehow link them myself to ensure that a slot
called on the 2nd PersonReplica ends up in the correct PersonSource?
• Can I add/remove Persons both from client and server side?
The idea of QtRO is that where a "normal" app would have all QObjects and UI
elements in a single process, QtRO lets you split into multiple processes or
devices. But you shouldn't have to redesign the object structure, instead you
just share the QObjects themselves. To the extent possible, given latency and
error conditions in communication, you shouldn't have to care whether the
QObjects are in another process or not.
From that perspective, what you are asking isn't really how QtRO works, you are
(in effect) asking how your apps/processes should be designed. How would you
implement these classes if they were in one process?
QAIM classes have signals for when chunks of the model change, not individual
signals. They just behave differently, and if you aren't familiar with how
they work, I'd recommend reviewing that first
(https://doc.qt.io/qt-5/model-view-programming.html). A QAIM over QtRO works
just the same as if the model were local. If you need additional methods to
add data to the model, those would need to be additional slots that you'd have
to implement yourself on the Source side. This might be the right direction to
go, but it might not be.
I've only rarely seen a case where a QList of QObject pointers is the right
design. If the list is dynamic, connecting signals of those objects to slots
of other objects gets to be complex and error prone. That would get compounded
by the additional error states involved with QtRO.
One alternative, instead of having the fundamental shared object be a
household, would be to have a Person class as the shared type. You can have
multiple source/replica objects of the same type, as long as each is given a
distinct name. The Household could potentially be only in the UI process,
consolidating the individual Person replicas.
I'm not sure what the right design is for your use-case, but hopefully the
above gives an idea of what some of the options are and how one might select
from them.
Good luck,
Brett
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
