[Interest] remoteobject returning a list of remoteobjects

[Marc Van Daele]

Thanks for the feedback!

Marc

On Tue, 23 Apr 2019 at 15:27, Stottlemyer, Brett (B.S.) <bstottle at ford.com>
wrote:

> On 4/22/19, 10:10 AM, "Marc Van Daele" <marc.van.daele90 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190423/4e1195c1/attachment.html>