I have a C++ QObject-derived class that exposes properties for use in QML, works fine (Qt5).
WHAT I WANT: I would like to instantiate an "instance" of this class in each of two processes, where changes in one "notifies" the other (in the other process). This is logically something like "local-instance-reflection" to a remote instance in a remote process. (I could create a second class-type if needed, but current implementation suggests I could instantiate the same class type on each side.) My current thoughts are to use a "socket" between the two processes, where the objects "agree" on a unique identifier that represents that "reflected-instance" in each process. Then, the implementation would trigger "onChange" operations in the remote-instance from property-changes in the local-instance. There would be many of these "reflecting-pairs". This "implementation-plumbing" would probably be through some C++ implemented dispatcher, where one would be instantiated in each process, and be responsible for the serialization for state-changes/notifications between the processes (read/write), and routing the notification to the object in the local process. A concern I have is that there will be *many* of these pairs (thousands, possibly tens-of-thousands), and I don't know if the approach would scale-well for lots of notifications. Does this design seem reasonable? Do you have thoughts on an alternative? It seems like the "Q_PROPERTY" notification through QML would be an interesting mechanism to enable this "generic-cross-process" event-based-synchronization. I can't use shared memory, as these processes will typically be on different machines. --charley
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
