Using Qt Remote Objects

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.

Voted #1 for:

  • Easiest to learn
  • Most time saving
  • Best support

Develop Cross-Platform Apps and Games 50% Faster!

  • Voted the best supported, most time-saving and easiest to learn cross-platform development tool
  • Based on the Qt framework, with native performance and appearance on all platforms including iOS and Android
  • Offers a variety of plugins to monetize, analyze and engage users
create apps
create games
cross platform
native performance
3rd party services
game network
level editor
easiest to learn
biggest time saving
best support