DBus-1-TQt
1.0
|
Contents:
The TQt3 bindings do not support autogeneration of service objects yet. In order to provide interfaces over D-Bus, an application has to implement the TQT_DBusObjectBase interface and register an instance of the resulting class with the TQT_DBusConnection.
When an application connects to D-Bus it gets a unique name generated by the bus daemon.
However, an application providing service will often want to be reachable under a fixed name, like a webserver being reachable through a domain name independent from its actual IP address. See section Service names for details on service names.
In order to get such a specific name an application has to request it using TQT_DBusConnection::requestName()
The example above request "org.example.SortService"
but continues with the default unique name in the case some other application is currently owning that name.
To make service objects available to other applications on the same bus the application has to register the objects instances with the connection to the bus using TQT_DBusConnection::registerObject()
Registering means to specify an object path where the object will be located, i.e. how it can be unambiguously be addressed in method calls. See section Object paths for details on object paths.
If the applications has introspectable objects it is recommended to register an introspectable root object, i.e. using "/"
as the path, so other applications have a common place to start asking for introspection data.
In the example above a service object providing sorting services on lists is registered on the path "/ListSorter"
D-Bus methods and signals of a service object a grouped into interfaces.
See section Interface names for details on interface naming.
An object can implement any number of interfaces, for example the interface for the functionality it wants to provide and a D-Bus standard interface like "org.freedesktop.DBus.Introspectable"
for providing an XML description of all its interfaces.
The service object of the example above implements just one interface "org.example.Sort"
and its handleMethodCall() explicitly checks all received messages and rejects any messsage not sent to this particular interface by returning false
and thus telling the D-Bus layer to generate a standard error response.
Multiple interfaces can of course be directly implemented in one C++ class, however it might sometimes be wise to delegate calls for different interfaces to different implementations: