25
submitted 5 months ago* (last edited 5 months ago) by [email protected] to c/[email protected]

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.

top 10 comments
sorted by: hot top controversial new old
[-] [email protected] 4 points 5 months ago* (last edited 5 months ago)

this has also been my (limited) experience with dbus. Unusable for mere mortals (people who don't have extensive experience with it and don't have time to just read the source code and piece it together), by way of being almost completely undocumented.

It seems like a really useful thing that would be 5x better if it was more easily usable/documented

[-] [email protected] 3 points 5 months ago

GTK+ is kind of similar in this regard, but at least there are hundreds of codebases to look at to figure out how the hell people are doing things in practice.

[-] [email protected] 1 points 5 months ago* (last edited 5 months ago)

yeah, I used a python gtk library a long time ago and it was pretty baffling, but I was able to do what I wanted to do, with some effort. It's really frustrating that there's this miasmatic layer floating over the very solid base that is GNU/Linux, of byzantine poorly documented libraries and APIs and shit. You, as a programming literate superuser, want to tweak the behavior of some GNOME app on your ubuntu system? good fucking luck it'll take you all week. Makes me start to understand the people that insist on "suckless" (I think I'm using that word right) software that is simple and flexible and customizable from the ground up, tiling window managers, systemd alternatives, etc.

I don't know if I'm fully on board with "no systemd, no traditional/consolidated dwm, etc." but I like the idea of being able to customize shit better than just "live with whatever you get or learn GTK/Vala/whatever" (or hack around the bad behavior on the CLI I guess)

[-] [email protected] 1 points 5 months ago

I unironically hope "document how to use this code" for stuff like is a good use for LLMs.

Let AI do the "boring" work

[-] [email protected] 3 points 5 months ago

It's terrible for this. It'll generate slightly broken documentation that looks plausible.

It's a great way to make everyone write the same fragile and incorrect code.

[-] [email protected] 3 points 5 months ago

I wish they didn't exist more than anything. I don't want to see them, I don't want to learn them and how to interpret and coax their garbled pronouncements, but if they actually become genuinely good at things like this that would be an acceptable outcome too. Its a shame they won't. Maybe they could do better than nothing though!

[-] [email protected] 3 points 5 months ago* (last edited 5 months ago)

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.

[-] [email protected] 2 points 5 months ago

BlueZ was my introduction to dbus too. Shit sucks lol. I had an easier time using reflection to access undocumented, hidden Bluetooth API's for Android's Bluetooth stack.

[-] [email protected] 1 points 5 months ago

bluez sucks ass and I'm sorry you had to deal with the Android stack

[-] [email protected] 1 points 5 months ago* (last edited 5 months ago)

No offense, but free desktop seems like a pile of trash. I'd rather run android user space.

I admittedly use KDE and I've only experimented with Linux x86 as a desktop environment, but it seems like free desktop is in a perpetual state of barely being usable by both devs and users.

this post was submitted on 31 Mar 2024
25 points (100.0% liked)

libre

9656 readers
4 users here now

Welcome to libre

A comm dedicated to the fight for free software with an anti-capitalist perspective.

The struggle for libre computing cannot be disentangled from other forms of socialist reform. One must be willing to reject proprietary software as fiercely as they would reject capitalism. Luckily, we are not alone.

libretion

Resources

  1. Free Software, Free Society provides an excellent primer in the origins and theory around free software and the GNU Project, the pioneers of the Free Software Movement.
  2. Switch to GNU/Linux! If you're still using Windows in $CURRENT_YEAR, flock to Linux Mint!; Apple Silicon users will want to check out Asahi Linux.
  3. Social Media Recommendations:

Rules

  1. Be on topic: Posts should be about free software and other hacktivst struggles. Topics about general tech news should be in the technology comm or programming comm.
  2. Avoid using misleading terms/speading misinformation: Here's a great article about what those words are. In short, try to avoid parroting common Techbro lingo and topics.
  3. Avoid being confrontational: People are in different stages of liberating their computing, focus on informing rather than accusing. Debatebro nonsense is not tolerated.
  4. All site-wide rules still apply

Artwork

founded 3 years ago
MODERATORS