Consider a sensor; a global positioning system (GPS) receiver for instance. In QtRO terms, the Source would be the process that directly interacts with the GPS hardware and derives your current location. The location would be exposed as QObject properties, and the periodic updates to the location would update the properties and emit property changed signals. Replicas would be created in other processes and would always know your current location, but would not need any of the logic to compute the location from the sensor data. Connecting to the location changed signal on the Replica would work as expected, as the signal emitted from the Source would trigger the signal emission on every Replica.

Another example of QtRO usage would be for a service (for example, access to a printer). The Source is again the process controlling the printer directly. Here you would again likely have properties monitoring the ink levels or whether the printer is currently busy. However, the key feature, being able to print something, needs to be passed back to the printer. This aligns with the Qt slot mechanism, which QtRO uses as the way for Replicas to make calls on the Source. In effect, properties and signals go from Source to Replicas, while slots go from (a) Replica to the Source. Assuming a print request is accepted, the printer status would change, which would change the status property. This would then be reported to all Replicas.