1GDBUS-CODEGEN(1) User Commands GDBUS-CODEGEN(1)
2
6 gdbus-codegen - D-Bus code and documentation generator
7
9 gdbus-codegen [-h, --help] [--interface-prefix org.project.Prefix]
10 [--generate-c-code OUTFILES] [--c-namespace YourProject]
11 [--c-generate-object-manager]
12 [--c-generate-autocleanup none|objects|all]
13 [--output-directory OUTDIR] [--generate-docbook OUTFILES]
14 [--pragma-once] [--xml-files FILE] [--header] [--body]
15 [--interface-info-header] [--interface-info-body]
16 [--output OUTFILE] [--annotate ELEMENT KEY VALUE]...
17 FILE [FILE...]
18
20 gdbus-codegen is used to generate code and/or documentation for one or
21 more D-Bus interfaces.
22 gdbus-codegen reads D-Bus Introspection XML[1] from files passed as
24 additional arguments on the command line and generates output files. It
25 currently supports generating C source code (via --body) or header (via
26 --header) and Docbook XML (via --generate-docbook). Alternatively, more
27 restricted C source code and headers can be generated, which just
28 contain the interface information (as GDBusInterfaceInfo structures)
29 using --interface-info-body and --interface-info-header.
30
32 When generating C code, a #GInterface -derived type is generated for
33 each D-Bus interface. Additionally, for every generated type, FooBar,
34 two concrete instantiable types, FooBarProxy and FooBarSkeleton,
35 implementing said interface are also generated. The former is derived
36 from #GDBusProxy and intended for use on the client side while the
37 latter is derived from the #GDBusInterfaceSkeleton type making it easy
38 to export on a #GDBusConnection either directly or via a
39 #GDBusObjectManagerServer instance.
40 For C code generation either --body that generates source code,
42 --header that generates headers, --interface-info-body that generates
43 interface information source code, or --interface-info-header that
44 generates interface information headers, can be used. These options
45 must be used along with --output, which is used to specify the file to
46 output to.
47 Both files can be generated at the same time by using
49 --generate-c-code, but this option is deprecated. In this case --output
50 cannot be used due to the generation of multiple files. Instead pass
51 --output-directory to specify the directory to put the output files in.
52 By default the current directory will be used.
53 The name of each generated C type is derived from the D-Bus interface
55 name stripped with the prefix given with --interface-prefix and with
56 the dots removed and initial characters capitalized. For example, for
57 the D-Bus interface com.acme.Coyote the name used is ComAcmeCoyote. For
58 the D-Bus interface org.project.Bar.Frobnicator with --interface-prefix
59 org.project., the name used is BarFrobnicator.
60 For methods, signals and properties, if not specified, the name
62 defaults to the name of the method, signal or property.
63 Two forms of the name are used - the CamelCase form and the lower-case
65 form. The CamelCase form is used for the #GType and struct name, while
66 lower-case form is used in function names. The lower-case form is
67 calculated by converting from CamelCase to lower-case and inserting
68 underscores at word boundaries (using certain heuristics).
69 If the value given by the org.gtk.GDBus.C.Name annotation or the
71 --c-namespace option contains an underscore (sometimes called
72 Ugly_Case), then the camel-case name is derived by removing all
73 underscores, and the lower-case name is derived by lower-casing the
74 string. This is useful in some situations where abbreviations are used.
75 For example, if the annotation is used on the interface
76 net.MyCorp.MyApp.iSCSITarget with the value iSCSI_Target the CamelCase
77 form is iSCSITarget while the lower-case form is iscsi_target. If the
78 annotation is used on the method EjectTheiPod with the value
79 Eject_The_iPod, the lower-case form is eject_the_ipod.
80
82 Each generated Docbook XML file (see the --generate-docbook option for
83 details) is a RefEntry[2] article describing the D-Bus interface.
84
86 The following options are supported:
87 -h, --help
89 Show help and exit.
90 --xml-files FILE
92 This option is deprecated; use positional arguments instead. The
93 D-Bus introspection XML file.
94 --interface-prefix org.project.Prefix.
96 A prefix to strip from all D-Bus interface names when calculating
97 the typename for the C binding and the Docbook sortas attribute[3].
98 --generate-docbook OUTFILES
100 Generate Docbook Documentation for each D-Bus interface and put it
101 in OUTFILES-NAME.xml where NAME is a place-holder for the interface
102 name, e.g. net.Corp.FooBar and so on.
103 Pass --output-directory to specify the directory to put the output
105 files in. By default the current directory will be used.
106 --generate-c-code OUTFILES
108 Generate C code for all D-Bus interfaces and put it in OUTFILES.c
109 and OUTFILES.h including any sub-directories. If you want the files
110 to be output in a different location use --output-directory as
111 OUTFILES.h including sub-directories will be referenced from
112 OUTFILES.c.
113 The full paths would then be $(OUTDIR)/$(dirname
115 $OUTFILES)/$(basename $OUTFILES).{c,h}.
116 --c-namespace YourProject
118 The namespace to use for generated C code. This is expected to be
119 in CamelCase[4] or Ugly_Case (see above).
120 --pragma-once
122 If this option is passed, the #pragma once[5] preprocessor
123 directive is used instead of include guards.
124 --c-generate-object-manager
126 If this option is passed, suitable #GDBusObject, #GDBusObjectProxy,
127 #GDBusObjectSkeleton and #GDBusObjectManagerClient subclasses are
128 generated.
129 --c-generate-autocleanup none|objects|all
131 This option influences what types autocleanup functions are
132 generated for. 'none' means to not generate any autocleanup
133 functions. 'objects' means to generate them for object types, and
134 'all' means to generate them for object types and interfaces. The
135 default is 'objects' due to a corner case in backwards
136 compatibility with a few projects, but you should likely switch
137 your project to use 'all'. This option was added in GLib 2.50.
138 --output-directory OUTDIR
140 Directory to output generated source to. Equivalent to changing
141 directory before generation.
142 This option cannot be used with --body, --header,
144 --interface-info-body or --interface-info-header; and --output must
145 be used.
146 --header
148 If this option is passed, it will generate the header code and
149 write it to the disk by using the path and file name provided by
150 --output.
151 Using --generate-c-code, --generate-docbook or --output-directory
153 are not allowed to be used along with --header and --body options,
154 because these options are used to generate only one file.
155 --body
157 If this option is passed, it will generate the source code and
158 write it to the disk by using the path and file name provided by
159 --output.
160 Using --generate-c-code, --generate-docbook or --output-directory
162 are not allowed to be used along with --header and --body options,
163 because these options are used to generate only one file.
164 --interface-info-header
166 If this option is passed, it will generate the header code for the
167 GDBusInterfaceInfo structures only and will write it to the disk by
168 using the path and file name provided by --output.
169 Using --generate-c-code, --generate-docbook or --output-directory
171 are not allowed to be used along with the --interface-info-header
172 and --interface-info-body options, because these options are used
173 to generate only one file.
174 --interface-info-body
176 If this option is passed, it will generate the source code for the
177 GDBusInterfaceInfo structures only and will write it to the disk by
178 using the path and file name provided by --output.
179 Using --generate-c-code, --generate-docbook or --output-directory
181 are not allowed to be used along with the --interface-info-header
182 and --interface-info-body options, because these options are used
183 to generate only one file.
184 --output OUTFILE
186 The full path where the header (--header, --interface-info-header)
187 or the source code (--body, --interface-info-body) will be written,
188 using the path and filename provided by --output. The full path
189 could be something like $($OUTFILE).{c,h}.
190 Using --generate-c-code, --generate-docbook or --output-directory
192 is not allowed along with --output, because the latter is used to
193 generate only one file.
194 --annotate ELEMENT KEY VALUE
196 Used to inject D-Bus annotations into the given XML files. It can
197 be used with interfaces, methods, signals, properties and arguments
198 in the following way:
199 gdbus-codegen --c-namespace MyApp \
201 --generate-c-code myapp-generated \
202 --annotate "org.project.InterfaceName" \
203 org.gtk.GDBus.C.Name MyFrobnicator \
204 --annotate "org.project.InterfaceName:Property" \
205 bar bat \
206 --annotate "org.project.InterfaceName.Method()" \
207 org.freedesktop.DBus.Deprecated true \
208 --annotate "org.project.InterfaceName.Method()[arg_name]" \
209 snake hiss \
210 --annotate "org.project.InterfaceName::Signal" \
211 cat meow \
212 --annotate "org.project.InterfaceName::Signal[arg_name]" \
213 dog wuff \
214 myapp-dbus-interfaces.xml
215 Any UTF-8 string can be used for KEY and VALUE.
216
218 The following D-Bus annotations are supported by gdbus-codegen:
219 org.freedesktop.DBus.Deprecated
221 Can be used on any <interface>, <method>, <signal> and <property>
222 element to specify that the element is deprecated if its value is
223 true. Note that this annotation is defined in the D-Bus
224 specification[1] and can only assume the values true and false. In
225 particular, you cannot specify the version that the element was
226 deprecated in nor any helpful deprecation message. Such information
227 should be added to the element documentation instead.
228 When generating C code, this annotation is used to add
230 #G_GNUC_DEPRECATED to generated functions for the element.
231 When generating Docbook XML, a deprecation warning will appear
233 along the documentation for the element.
234 org.gtk.GDBus.Since
236 Can be used on any <interface>, <method>, <signal> and <property>
237 element to specify the version (any free-form string but compared
238 using a version-aware sort function) the element appeared in.
239 When generating C code, this field is used to ensure function
241 pointer order for preserving ABI/API, see the section called
242 “STABILITY GUARANTEES”.
243 When generating Docbook XML, the value of this tag appears in the
245 documentation.
246 org.gtk.GDBus.DocString
248 A string with Docbook content for documentation. This annotation
249 can be used on <interface>, <method>, <signal>, <property> and
250 <arg> elements.
251 org.gtk.GDBus.DocString.Short
253 A string with Docbook content for short/brief documentation. This
254 annotation can only be used on <interface> elements.
255 org.gtk.GDBus.C.Name
257 Can be used on any <interface>, <method>, <signal> and <property>
258 element to specify the name to use when generating C code. The
259 value is expected to be in CamelCase[4] or Ugly_Case (see above).
260 org.gtk.GDBus.C.ForceGVariant
262 If set to a non-empty string, a #GVariant instance will be used
263 instead of the natural C type. This annotation can be used on any
264 <arg> and <property> element.
265 org.gtk.GDBus.C.UnixFD
267 If set to a non-empty string, the generated code will include
268 parameters to exchange file descriptors using the #GUnixFDList
269 type. This annotation can be used on <method> elements.
270 As an easier alternative to using the org.gtk.GDBus.DocString
272 annotation, note that parser used by gdbus-codegen parses XML comments
273 in a way similar to gtk-doc[6]:
274 Note that @since can be used in any inline documentation bit (e.g. for
276 interfaces, methods, signals and properties) to set the
277 org.gtk.GDBus.Since annotation. For the org.gtk.GDBus.DocString
278 annotation (and inline comments), note that substrings of the form
279 #net.Corp.Bar, net.Corp.Bar.FooMethod(), #net.Corp.Bar::BarSignal and
280 #net.Corp.InlineDocs:BazProperty are all expanded to links to the
281 respective interface, method, signal and property. Additionally,
282 substrings starting with @ and % characters are rendered as
283 parameter[7] and constant[8] respectively.
284 If both XML comments and org.gtk.GDBus.DocString or
286 org.gtk.GDBus.DocString.Short annotations are present, the latter wins.
287
289 Consider the following D-Bus Introspection XML.
290 <node>
292 <interface name="net.Corp.MyApp.Frobber">
293 <method name="HelloWorld">
294 <arg name="greeting" direction="in" type="s"/>
295 <arg name="response" direction="out" type="s"/>
296 </method>
297 <signal name="Notification">
299 <arg name="icon_blob" type="ay"/>
300 <arg name="height" type="i"/>
301 <arg name="messages" type="as"/>
302 </signal>
303 <property name="Verbose" type="b" access="readwrite"/>
305 </interface>
306 </node>
307 If gdbus-codegen is used on this file like this:
309 gdbus-codegen --generate-c-code myapp-generated \
311 --c-namespace MyApp \
312 --interface-prefix net.corp.MyApp. \
313 net.Corp.MyApp.Frobber.xml
314 two files called myapp-generated.[ch] are generated. The files provide
316 an abstract #GTypeInterface -derived type called MyAppFrobber as well
317 as two instantiable types with the same name but suffixed with Proxy
318 and Skeleton. The generated file, roughly, contains the following
319 facilities:
320 /* GType macros for the three generated types */
322 #define MY_APP_TYPE_FROBBER (my_app_frobber_get_type ())
323 #define MY_APP_TYPE_FROBBER_SKELETON (my_app_frobber_skeleton_get_type ())
324 #define MY_APP_TYPE_FROBBER_PROXY (my_app_frobber_proxy_get_type ())
325 typedef struct _MyAppFrobber MyAppFrobber; /* Dummy typedef */
327 typedef struct
329 {
330 GTypeInterface parent_iface;
331 /* Signal handler for the ::notification signal */
333 void (*notification) (MyAppFrobber *proxy,
334 GVariant *icon_blob,
335 gint height,
336 const gchar* const *messages);
337 /* Signal handler for the ::handle-hello-world signal */
339 gboolean (*handle_hello_world) (MyAppFrobber *proxy,
340 GDBusMethodInvocation *invocation,
341 const gchar *greeting);
342 } MyAppFrobberIface;
343 /* Asynchronously calls HelloWorld() */
345 void
346 my_app_frobber_call_hello_world (MyAppFrobber *proxy,
347 const gchar *greeting,
348 GCancellable *cancellable,
349 GAsyncReadyCallback callback,
350 gpointer user_data);
351 gboolean
352 my_app_frobber_call_hello_world_finish (MyAppFrobber *proxy,
353 gchar **out_response,
354 GAsyncResult *res,
355 GError **error);
356 /* Synchronously calls HelloWorld(). Blocks calling thread. */
358 gboolean
359 my_app_frobber_call_hello_world_sync (MyAppFrobber *proxy,
360 const gchar *greeting,
361 gchar **out_response,
362 GCancellable *cancellable,
363 GError **error);
364 /* Completes handling the HelloWorld() method call */
366 void
367 my_app_frobber_complete_hello_world (MyAppFrobber *object,
368 GDBusMethodInvocation *invocation,
369 const gchar *response);
370 /* Emits the ::notification signal / Notification() D-Bus signal */
372 void
373 my_app_frobber_emit_notification (MyAppFrobber *object,
374 GVariant *icon_blob,
375 gint height,
376 const gchar* const *messages);
377 /* Gets the :verbose GObject property / Verbose D-Bus property.
379 * Does no blocking I/O.
380 */
381 gboolean my_app_frobber_get_verbose (MyAppFrobber *object);
382 /* Sets the :verbose GObject property / Verbose D-Bus property.
384 * Does no blocking I/O.
385 */
386 void my_app_frobber_set_verbose (MyAppFrobber *object,
387 gboolean value);
388 /* Gets the interface info */
390 GDBusInterfaceInfo *my_app_frobber_interface_info (void);
391 /* Creates a new skeleton object, ready to be exported */
393 MyAppFrobber *my_app_frobber_skeleton_new (void);
394 /* Client-side proxy constructors.
396 *
397 * Additionally, _new_for_bus(), _new_for_bus_finish() and
398 * _new_for_bus_sync() proxy constructors are also generated.
399 */
400 void
401 my_app_frobber_proxy_new (GDBusConnection *connection,
402 GDBusProxyFlags flags,
403 const gchar *name,
404 const gchar *object_path,
405 GCancellable *cancellable,
406 GAsyncReadyCallback callback,
407 gpointer user_data);
408 MyAppFrobber *
409 my_app_frobber_proxy_new_finish (GAsyncResult *res,
410 GError **error);
411 MyAppFrobber *
412 my_app_frobber_proxy_new_sync (GDBusConnection *connection,
413 GDBusProxyFlags flags,
414 const gchar *name,
415 const gchar *object_path,
416 GCancellable *cancellable,
417 GError **error);
418 Thus, for every D-Bus method, there will be three C functions for
420 calling the method, one #GObject signal for handling an incoming call
421 and one C function for completing an incoming call. For every D-Bus
422 signal, there's one #GObject signal and one C function for emitting it.
423 For every D-Bus property, two C functions are generated (one setter,
424 one getter) and one #GObject property. The following table summarizes
425 the generated facilities and where they are applicable:
426 ┌───────────┬─────────────────────┬──────────────────────────────┐
428 │ │ Client │ Server │
429 ├───────────┼─────────────────────┼──────────────────────────────┤
430 │Types │ Use │ Any type │
431 │ │ MyAppFrobberProxy │ implementing the │
432 │ │ │ MyAppFrobber │
433 │ │ │ interface │
434 ├───────────┼─────────────────────┼──────────────────────────────┤
435 │Methods │ Use │ Receive via the │
436 │ │ m_a_f_hello_world() │ handle_hello_world() │
437 │ │ to call. │ signal handler. │
438 │ │ │ Complete the call │
439 │ │ │ with │
440 │ │ │ m_a_f_complete_hello_world() │
441 ├───────────┼─────────────────────┼──────────────────────────────┤
442 │Signals │ Connect to the │ Use │
443 │ │ ::notification │ m_a_f_emit_notification() to │
444 │ │ GObject signal. │ emit signal. │
445 ├───────────┼─────────────────────┼──────────────────────────────┤
446 │Properties │ Use │ Implement #GObject's │
447 │(Reading) │ m_a_f_get_verbose() │ get_property() vfunc. │
448 │ │ or :verbose. │ │
449 ├───────────┼─────────────────────┼──────────────────────────────┤
450 │Properties │ Use │ Implement #GObject's │
451 │(writing) │ m_a_f_set_verbose() │ set_property() vfunc. │
452 │ │ or :verbose. │ │
453 └───────────┴─────────────────────┴──────────────────────────────┘
454 Client-side usage
456 You can use the generated proxy type with the generated constructors:
457 MyAppFrobber *proxy;
459 GError *error;
460 error = NULL;
462 proxy = my_app_frobber_proxy_new_for_bus_sync (
463 G_BUS_TYPE_SESSION,
464 G_DBUS_PROXY_FLAGS_NONE,
465 "net.Corp.MyApp", /* bus name */
466 "/net/Corp/MyApp/SomeFrobber", /* object */
467 NULL, /* GCancellable* */
468 &error);
469 /* do stuff with proxy */
470 g_object_unref (proxy);
471 Instead of using the generic #GDBusProxy facilities, one can use the
473 generated methods such as my_app_frobber_call_hello_world() to invoke
474 the net.Corp.MyApp.Frobber.HelloWorld() D-Bus method, connect to the
475 ::notification GObject signal to receive the
476 net.Corp.MyApp.Frobber::Notication D-Bus signal and get/set the
477 net.Corp.MyApp.Frobber:Verbose D-Bus Property using either the GObject
478 property :verbose or the my_app_get_verbose() and my_app_set_verbose()
479 methods. Use the standard #GObject::notify signal to listen to property
480 changes.
481 Note that all property access is via #GDBusProxy 's property cache so
483 no I/O is ever done when reading properties. Also note that setting a
484 property will cause the org.freedesktop.DBus.Properties.Set[9] method
485 to be called on the remote object. This call, however, is asynchronous
486 so setting a property won't block. Further, the change is delayed and
487 no error checking is possible.
488 Server-side usage
490 The generated MyAppFrobber interface is designed so it is easy to
491 implement it in a #GObject subclass. For example, to handle
492 HelloWorld() method invocations, set the vfunc for
493 handle_hello_hello_world() in the MyAppFrobberIface structure.
494 Similarly, to handle the net.Corp.MyApp.Frobber:Verbose property
495 override the :verbose #GObject property from the subclass. To emit a
496 signal, use e.g. my_app_emit_signal() or g_signal_emit_by_name().
497 Instead of subclassing, it is often easier to use the generated
499 MyAppFrobberSkeleton subclass. To handle incoming method calls, use
500 g_signal_connect() with the ::handle-* signals and instead of
501 overriding #GObject 's get_property() and set_property() vfuncs, use
502 g_object_get() and g_object_set() or the generated property getters and
503 setters (the generated class has an internal property bag
504 implementation).
505 static gboolean
507 on_handle_hello_world (MyAppFrobber *interface,
508 GDBusMethodInvocation *invocation,
509 const gchar *greeting,
510 gpointer user_data)
511 {
512 if (g_strcmp0 (greeting, "Boo") != 0)
513 {
514 gchar *response;
515 response = g_strdup_printf ("Word! You said `%s'.", greeting);
516 my_app_complete_hello_world (interface, invocation, response);
517 g_free (response);
518 }
519 else
520 {
521 g_dbus_method_invocation_return_error (invocation,
522 MY_APP_ERROR,
523 MY_APP_ERROR_NO_WHINING,
524 "Hey, %s, there will be no whining!",
525 g_dbus_method_invocation_get_sender (invocation));
526 }
527 return TRUE;
528 }
529 [...]
531 interface = my_app_frobber_skeleton_new ();
533 my_app_frobber_set_verbose (interface, TRUE);
534 g_signal_connect (interface,
536 "handle-hello-world",
537 G_CALLBACK (on_handle_hello_world),
538 some_user_data);
539 [...]
541 error = NULL;
543 if (!g_dbus_interface_skeleton_export (G_DBUS_INTERFACE_SKELETON (interface),
544 connection,
545 "/path/of/dbus_object",
546 &error))
547 {
548 /* handle error */
549 }
550 To facilitate atomic changesets (multiple properties changing at the
552 same time), #GObject::notify signals are queued up when received. The
553 queue is drained in an idle handler (which is called from the
554 thread-default main loop of the thread where the skeleton object was
555 constructed) and will cause emissions of the
556 org.freedesktop.DBus.Properties::PropertiesChanged[9] signal with all
557 the properties that have changed. Use g_dbus_interface_skeleton_flush()
558 or g_dbus_object_skeleton_flush() to empty the queue immediately. Use
559 g_object_freeze_notify() and g_object_thaw_notify() for atomic
560 changesets if on a different thread.
561
563 Scalar types (type-strings 'b', 'y', 'n', 'q', 'i', 'u', 'x', 't' and
564 'd') ), strings (type-strings 's', 'ay', 'o' and 'g') and arrays of
565 string (type-strings 'as', 'ao' and 'aay') are mapped to the natural
566 types, e.g. #gboolean, #gdouble, #gint, gchar*, gchar** and so on.
567 Everything else is mapped to the #GVariant type.
568 This automatic mapping can be turned off by using the annotation
570 org.gtk.GDBus.C.ForceGVariant - if used then a #GVariant is always
571 exchanged instead of the corresponding native C type. This annotation
572 may be convenient to use when using bytestrings (type-string 'ay') for
573 data that could have embedded NUL bytes.
574
576 The generated C functions are guaranteed to not change their ABI that
577 is, if a method, signal or property does not change its signature in
578 the introspection XML, the generated C functions will not change its C
579 ABI either. The ABI of the generated instance and class structures will
580 be preserved as well.
581 The ABI of the generated #GType s will be preserved only if the
583 org.gtk.GDBus.Since annotation is used judiciously — this is because
584 the VTable for the #GInterface relies on functions pointers for signal
585 handlers. Specifically, if a D-Bus method, property or signal or is
586 added to a D-Bus interface, then ABI of the generated #GInterface type
587 is preserved if, and only if, each added method, property signal is
588 annotated with they org.gtk.GDBus.Since annotation using a greater
589 version number than previous versions.
590 The generated C code currently happens to be annotated with gtk-doc[6]
592 / GObject Introspection[10] comments / annotations. The layout and
593 contents might change in the future so no guarantees about e.g.
594 SECTION usage etc. is given.
595 While the generated Docbook for D-Bus interfaces isn't expected to
597 change, no guarantees are given at this point.
598 It is important to note that the generated code should not be checked
600 into revision control systems, nor it should be included in distributed
601 source archives.
602
604 Please send bug reports to either the distribution bug tracker or the
605 upstream bug tracker at https://gitlab.gnome.org/GNOME/glib/issues/new.
606
608 gdbus(1)
609
611 1. D-Bus Introspection XML
612 http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
613 2. RefEntry
615 http://www.docbook.org/tdg/en/html/refentry.html
616 3. sortas attribute
618 http://www.docbook.org/tdg/en/html/primary.html
619 4. CamelCase
621 http://en.wikipedia.org/wiki/CamelCase
622 5. #pragma once
624 https://en.wikipedia.org/wiki/Pragma_once
625 6. gtk-doc
627 http://www.gtk.org/gtk-doc/
628 7. parameter
630 http://www.docbook.org/tdg/en/html/parameter.html
631 8. constant
633 http://www.docbook.org/tdg/en/html/constant.html
634 9. org.freedesktop.DBus.Properties.Set
636 http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties
637 10. GObject Introspection
639 https://wiki.gnome.org/Projects/GObjectIntrospection
640GIO GDBUS-CODEGEN(1)