D-Bus is a common mechanism for inter-process communication used on Linux. It allows applications and services to present a collection of properties and methods, as well as interact with the properties and methods of other process. It is used extensively by modern desktop environments. It is the canonical interface to interact with BlueZ, the main Bluetooth stack on Linux, as well as UPower.
D-Bus is implemented in C, and it provides libdbus - also implemented in C - to use it. But libdbus has little to no documentation. Just a light Doxygen reference of functions, structs, macros, etc. The main intoduction says explicitly, “This manual documents the low-level D-Bus C API. If you use this low-level API directly, you’re signing up for some pain.” Other pages on the freedesktop website recommends using other language bindings - like gdbus (which isn’t a binding, but a re-implementation of the wire protocol), which has almost the same interface and even less documentation.
What the fuck are we even doing here? “Yeah this is dogshit, but it’s okay because it’s supposed to be used through a wrapper library which (for C) doesn’t exist without various strings (gobject / qt / systemd) attached.” I don’t want a dependency on QT to dick around with BlueZ, and I sure as hell don’t want to dive down the whole gobject rabbit hole just to write a program in C anyway.
I don’t understand how such robust infrastructure gets built with this attitude. Clearly it still happens, so I must be missing something.
I’ve been using the Java bindings/dbus client implementation and they rock lol. So easy to use.
Using C in general is asking for trouble. Especially for an object oriented API with its own object model.
It seems like there’s some Rust bindings for dbus at https://github.com/diwic/dbus-rs including a code generator, which is how you should be accessing dbus APIs, since it’s so much more readable and maintainable, and potentially more performant, than manually setting up the methods/types.