PySide6.QtRemoteObjects#

Detailed Description#

Provides APIs for inter-process communication.

Remote Object Concepts#

Qt Remote Objects (QtRO) is an Inter-Process Communication (IPC) module developed for Qt. This module extends Qt’s existing functionalities to enable information exchange between processes or computers, easily.

One of Qt’s key features, to enable this information exchange, is the distinction between an object’s API (defined by its properties, signals, and slots) and the implementation of that API. QtRO’s purpose is to meet that expected API, even if the true QObject is in a different process. A slot called on a copy of an object (the Replica in QtRO) is forwarded to the true object (the Source in QtRO) for handling. Every Replica receives updates to the Source, either property changes or emitted signals.

A Replica is a light-weight proxy for the Source object, but a Replica supports the same connections and behavior of QObjects, which makes it usable in the same way as any other QObject that Qt provides. Behind the scenes, QtRO handles everything that’s necessary for the Replica to look like its Source.

Note that Remote Objects behave differently from traditional Remote Procedure Call (RPC) implementations, for example:

  • In RPC, the client makes a request and waits for the response.

  • In RPC, the server doesn’t push anything to the client unless it’s in response to a request.

  • Often, the design of RPC is such that different clients are independent of each other: for instance, two clients can ask a mapping service for directions and get different results.

While it is possible to implement this RPC-style behavior in QtRO, as Sources without properties, and slots that have return values, QtRO hides the fact that the processing is really remote. You let a node give you the Replica instead of creating it yourself, possibly use the status signals ( isReplicaValid() ), but then interact with the object like you would with any other QObject -based type.

Use Case: GPS#

Consider a sensor such as a Global Positioning System (GPS) receiver. 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; the periodic updates to the location would update these properties and emit property changed signals.

  • Replicas would be created in other processes and would always know your current location, but wouldn’t 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: the signal emitted from the Source would trigger the signal emission on every Replica.

Use Case: Printer Access#

Consider a service that provides access to a printer. In QtRO terms:

  • The Source would be the process controlling the printer directly.

  • The ink levels and printer status would be monitored by QObject properties. Updates to these properties would emit property changed signals.

  • The key feature – being able to print something – needs to be passed back to the printer. Incidentally, 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; slots go from Replica to Source.

  • When a print request is accepted, the printer status would change, triggering a change in the status property. This would then be reported to all Replicas.

Using the Module#

To include the definitions of modules classes, use the following directive:

import PySide6.QtRemoteObjects

Articles and Guides#

List of Classes#

A

Q

R