User Tools

Site Tools


Network and communication

k24:k24.9:k24.9.0:k24.9.0.1:start Gambas and D-Bus

The component gb.dbus consists of two parts: The core is written in C and is located in gb.dbus/src. Based on this, there is a part written in gambas and is located in the path gb.dbus/src/gb.dbus. For example, the class DBusVariant is written in C and is in the file c_dbusvariant.c, while the class DBusValue is completely programmed in Gambas.

As far as gambas and D-Bus are concerned, two strategies are generally pursued:

  • Use of existing services on the D-Bus and
  • Provision of services on the D-Bus with Gambas programs.

Implementing these strategies enables you to do the following for any d-bus-enabled application:

  • Call methods,
  • methods in exported D-Bus objects,
  • Read and set values of properties,
  • Interception of signals,
  • Send signals. Buses

D-Bus offers at least two buses for communication between processes. One is the global system bus and another is the session bus, to which every desktop of a logged on user is automatically connected within his desktop session. The default in Gambas is the session bus.

There are (at least) two D-Bus daemons running on a Linux system


You can also use the DBusView gambas program to get an overview of all programs currently registered on the D-Bus:


Figure Registered programs on the D-Bus

You can find the archive for the DBusView program in the download area of Chapter 24.9.2.

You can use the following commands to read out a list of applications that are registered on the system bus or on the session bus. The list contains the D-Bus names and the unique connection IDs assigned to them, which are always preceded by a colon. The program qdbus is used:

$ qdbus --session | grep -v ":"

$ qdbus --system | grep ":"


  • A Gambas program is automatically connected to the Session D-Bus when the component gb.dbus is loaded!
  • As soon as you export at least one D-Bus object to the D-Bus via the Register(…) method, your application on the D-Bus is called org.gambas. Application Name > registered. You can always use the property for <Application name>. D-Bus message

Communication on the system bus and the session bus takes place via messages - similar to sending packets in TCP/IP networks. In contrast to the TCP/IP protocol, however, D-Bus guarantees the transmission of all messages in one go. There are four types of D-Bus messages:

  • Method,
  • Reply,
  • Error,
  • signal.

Messages are sent or received as method calls or signals. Each call of a method is always acknowledged with a message - not only in the event of an error or the successful return of a value.

In the gambas class DBus (gb.dbus) the message types are declared using the four (integer) constants DBus.method (1), DBus.reply (2), DBus.error (3) and DBus.signal (4). D-Bus address

Since several applications - or their processes - can be connected to the system bus or the session bus, it is necessary to address each message uniquely. The address consists of the information

of the service (name of the application), the object path and (optionally) the interfaces. D-Bus-NameA service represents an active connection between a program and the System D-Bus or the Session D-Bus. This connection is described by the readable D-Bus name. A “ReverseDomainName” is used for this description. D-Bus names have the syntax: “ReverseDomainName”.application name. Note that D-Bus names are case-sensitive.

The syntax for D-Bus names in Gambas is: with xxx as the Gambas project name, which is provided under the value of the Application.Name property and used for xxx. These D-Bus names, for example, are correct:


If more than one instance of an application is registered on the D-Bus, the process ID is appended to the name of the service so that a unique D-Bus name exists for the connection.

At the same time, a unique ID is generated for each connection of an application to the D-Bus. This ID starts with a colon (:) followed by a sequence of digits, a period and another sequence of digits. For example, a valid ID would be :1.63 . D-Bus object

Objects provide access to interfaces. They are identified by identifiers such as /org/freedesktop/NetworkManager or /org/gambas/P2DBUS, whose syntax reminds of file paths. The following rules define a valid object path:

  • A path can have any length.
  • A path starts with the ASCII character '/' (ASCII decimal 47).
  • A single '/'-character stands for the root directory.
  • Multiple '/'-characters% (one after the other) are not allowed. * Each path element after a '/'-character%% contains only characters from “[A-Z][a-z][0-9]_” .
  • No element may be an empty string.
qdbus --session \
      org.gambas.export_dbus \
      /org/gambas/export_dbus \

Note: A d-bus-enabled application can ignore an incorrectly declared object path!

A valid address, for example, is made up of these three details:

  • Service (D-Bus name of the application)org.freedesktop.NetworkManager
  • Object Path (Path)/org/freedesktop/NetworkManager
  • Interface (Interface)org.freedesktop.DBus.Introspectable

and will be used as a valid address:

org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.DBus.Introspectable D-Bus interface (D-Bus interface)

An (active) interface has methods, properties and events as well as signals and is registered on the D-Bus. The description of an interface can be in an XML document to serve as a reference for developers and users (introspection).


The website uses a temporary session cookie. This technically necessary cookie is deleted when the browser is closed. You can find information on cookies in our privacy policy.
k24/k24.9/k24.9.0/k24.9.0.1/start.txt · Last modified: 02.07.2018 (external edit)

Page Tools