DBus-1-TQt 1.0
|
Contents:
While it is of course possible to just exchange D-Bus messages with a D-Bus service, it is a lot more comfortable to use TQT_DBusProxy.
With TQT_DBusProxy you only need to specify the service object once, i.e. its D-Bus name, path and interface, and just provide the method and its parameters when initiating an invokation.
Additionally the proxy transforms D-Bus signals from the proxy's peer (the D-Bus service object's interface it is associated with) to TQObject signal carrying the original signal's content.
A connection to the bus is acquired using TQT_DBusConnection::sessionBus()
Next, a proxy is created for the object "/org/freedesktop/DBus"
with interface "org.freedesktop.DBus"
on the service "org.freedesktop.DBus"
This is a proxy for the message bus itself.
There are two choices for method invocation:
As seen in the example code above, a synchronous method call can be achieved by TQT_DBusProxy::sendWithReply(). It sends a method call to the remote object, and blocks until reply is received. The outgoing arguments are specified as a list of TQT_DBusData.
To invoke a method asynchronously, connect the proxy's signal TQT_DBusProxy::asyncReply(int, const TQT_DBusMessage&) to a suitable slot like with any other TQt Signal-Slot connection.
Then call TQT_DBusProxy::sendWithAsyncReply() It returns a numerical identifier of the call, so it can be related in the slot once the result is available.
The slot's first argument is the reveived reply's call identifier as returned by the method call. The second parameter is the reply message similar to the one in the synchronous call.
To receive D-BUS signals just connect to the TQT_DBusProxy's signal TQT_DBusProxy::dbusSignal(const TQT_DBusMessage&)
It will be emitted whenever a D-Bus signal message is received from the peer object. Filtering of signals is based on the value set for service
, path
and interface
service
will only happen if service
is a unique D-Bus name, i.e. if it starts with a colon ":"
since D-Bus signals carry the sender's unique name and filtering by a requested name would reject all signalsUsually a proxy will be also be used to send to the peer object, thus having them all set. However if a proxy is only needed for signals, any of the three properties can be omitted (e.g. set to TQString()
), in which case only the available properties will be checked against the respective message field when deciding about dropping or emitting the message. See TQT_DBusProxy::handleDBusSignal()
If you want all signal travelling on the bus, or apply filtering for different criteria, e.g. get all signals coming from interfaces starting with "org."
, use TQT_DBusConnection::connect()
instead. The signature of the slot stays the same.
First declare a receiver class:
Then somewhere else in a source file:
receiver1
will get all signals on this connection
receiver2
will only get signals coming from the proxy's peer interface