dbus-binding-tool(1)

πŸ’… dbus-binding-tool(1) β€” the glow-up

okay bestie so this is a page from the User Commands manual, and it's about dbus-binding-tool, the C language dbus-glib bindings generation utility. yes it's a mouthful. we're gonna get through it together 🫢


✨ NAME ✨

dbus-binding-tool β€” C language dbus-glib bindings generation utility.


🌸 SYNOPSIS 🌸

dbus-binding-tool [--force] [--help] [--ignore-unsupported]
[--mode=pretty|glib-client|glib-server] [--output=file]
[--prefix=symbol-prefix] [--version] [file...]

πŸ¦‹ DESCRIPTION πŸ¦‹

so dbus-binding-tool is the little icon that lets you expose a GObject via D-Bus, using the deprecated dbus-glib binding for GLib. ⚠️ deprecated, bestie, we'll get into that later.

as input, dbus-binding-tool takes a D-Bus Introspection XML file. as output, it generates the client-side or server-side bindings. that output is a header file, and it lowkey exists to make using a remote D-Bus object way easier. the output goes to standard out, or to whatever filename you gave the --output argument. πŸ’–


πŸŽ€ EXTENDED DESCRIPTION πŸŽ€

here's a sample D-Bus Introspection XML file that describes an object exposing one method, named ManyArgs:

<?xml version="1.0" encoding="UTF-8" ?>
<node name="/com/example/MyObject">
  <interface name="com.example.MyObject">
    <method name="ManyArgs">
      <arg type="u" name="x" direction="in" />
      <arg type="s" name="str" direction="in" />
      <arg type="d" name="trouble" direction="in" />
      <arg type="d" name="d_ret" direction="out" />
      <arg type="s" name="str_ret" direction="out" />
    </method>
  </interface>
</node>

dbus-binding-tool also supports annotations in the XML format, so you can further control how the bindings get generated. πŸ‘‘

πŸ’œ client-side bindings

when you're building client-side bindings, you use the --mode=glib-client argument. these client-side bindings support the "org.freedesktop.DBus.GLib.NoReply" annotation. you put it inside the <method> tag to say the client isn't expecting a reply to the method call, so a reply should not be sent. this is often used to speed up rapid method calls where there are no "out" arguments β€” and honestly, not knowing if the method succeeded is an acceptable compromise to halve the traffic on the bus. trade-offs, bestie. πŸ’…

for example:

<method name "FooMethod">
  [...]
  <annotation name="org.freedesktop.DBus.GLib.NoReply" value="yes"/>
  [...]
</method>

🌈 server-side bindings

when you're building server-side bindings, you use the --mode=glib-server argument. also, the --prefix argument must be used when building server-side bindings, so functions in the generated output get prefexed with the specified value. (yes, "prefexed" is what the page says, we're keeping it, it's iconic 😭)

the server-side bindings support these annotations:

⭐ "org.freedesktop.DBus.GLib.CSymbol"

this annotation specifies the C symbol names for the various types (interface, method, etc.), if it differs from the name D-Bus generates.

<interface name="com.example.MyObject">
  <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="my_object"/>
  [...]
  <method name "ManyArgs">
    <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="my_object_many_args"/>
    [...]
  </method>
</interface>

πŸ”₯ "org.freedesktop.DBus.GLib.Async"

this annotation marks the method implementation as an asynchronous function β€” one that doesn't return a response straight away but will send the response at some later point to complete the call. it's used to implement non-blocking services where method calls can take time. ⏳

when a method is asynchronous, the function prototype is different. the function is required to conform to these rules:

  • the function must return a value of type gboolean; TRUE on success, and FALSE otherwise.
  • the first parameter is a pointer to an instance of the object.
  • following the object instance pointer are the method input values.
  • the final parameter must be a (DBusGMethodInvocation *). this is used when sending the response message back to the client, by calling dbus_g_method_return or dbus_g_method_return_error.

for example:

<method name "FooMethod">
  [...]
  <annotation name="org.freedesktop.DBus.GLib.Async" value="yes"/>
  [...]
</method>

🧚 "org.freedesktop.DBus.GLib.Const"

this attribute can only be applied to "out" <arg> nodes, and it specifies that the parameter is not being copied when returned. for example, this turns a 's' argument from a (char **) to a (const char **), and results in the argument not being freed by D-Bus after the message is sent. no cap.

<arg type="u" name="x" direction="out">
  <annotation name="org.freedesktop.DBus.GLib.Const" value=""/>
</arg>

πŸ’€ "org.freedesktop.DBus.GLib.ReturnVal"

this attribute can only be applied to "out" <arg> nodes, and it alters the expected function signature. right now it can be set to two values: "" or "error". the argument marked with this attribute is not returned via a pointer argument, but by the function's return value.

if the attribute's value is the empty string, the (GError *) argument is also omitted β€” so there's no standard way to return an error value. this is very useful for interfacing with existing code, since it's possible to match existing APIs. if the attribute's value is "error", then the final argument is a (GError *) as usual.

for example:

<arg type="u" name="x" direction="out">
  <annotation name="org.freedesktop.DBus.GLib.ReturnVal" value=""/>
</arg>

πŸ“ OPTIONS πŸ“

the following options are supported:

  • --force β€” overwrite the output file if it already exists with a newer timestamp than the source files.
  • --help β€” display usage information.
  • --ignore-unsupported β€” if set, then unsupported signatures for <method> parameters are ignored.
  • --mode=pretty|glib-client|glib-server β€” if the value is "glib-client", then client bindings are generated. if the value is "glib-server", then server bindings are generated. if the value is "pretty", then the output is in a more human readable format. πŸ’–
  • --output=file β€” specify the output file.
  • --prefix=symbol-prefix β€” functions in the generated output are prefixed with the symbol-prefix value.
  • --version β€” display the version number of the dbus-binding-tool command.

🫢 OPERANDS 🫢

the following operands are supported:

  • file β€” a list of one or more input D-Bus Introspection XML files to include in the generated output.

🌟 FILES 🌟

the following files are used by this application:

  • ${exec_prefix}/bin/dbus-binding- β€” Executable for the D-Bus Binding Tool application.

πŸ‘‘ SEE ALSO πŸ‘‘

gdbus-codegen(1), dbus-cleanup-sockets(1), dbus-daemon(1), dbus-monitor(1), dbus-send(1), dbus-uuidgen(1)


πŸ™ˆ NOTES πŸ™ˆ

dbus-binding-tool is part of dbus-glib, which is a deprecated D-Bus binding for GLib. ⚠️

dbus-glib receives minimal maintenance and security fixes for the benefit of projects like Telepathy and NetworkManager that still rely on it β€” but it should not be used in new projects (and existing projects should try to move away from it, too). please use GDBus, part of GLib since 2.26. πŸ¦‹

gdbus-codegen(1) is the GDBus replacement for dbus-binding-tool.


πŸ’– AUTHORS πŸ’–

man page written by Brian Cameron, Sun Microsystems Inc., 2009.


and that's the whole vibe check, bestie ✨ this page is from dbus-glib 0.116, dated 8 Oct 2018 β€” love that for us, now go forth and generate those bindings (or, y'know, migrate to GDBus like the notes literally beg you to πŸ’…πŸŽ€).

πŸ“¦ where this page comes from