Thanks for the feedback! Marc
On Tue, 23 Apr 2019 at 15:27, Stottlemyer, Brett (B.S.) <bstot...@ford.com> wrote: > 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
