[[!sidebar content=""]] [[!meta title="The Wheels on D-Bus"]] [[!meta copyright="Copyright © 2022 Ian Eure"]] [[!inline pages="internal(2022/info/dbus-nav)" raw="yes"]] # The Wheels on D-Bus Ian Eure (ee-uhn you-er, he/him/his, IRC: ieure) [[!inline pages="internal(2022/info/dbus-before)" raw="yes"]] In this talk, I’ll explore uses of D-Bus that supercharge your Emacs Operating System. # Discussion ## Notes - - - - re: "pushing mindshare"..  Yes, you were very successful on that! ## Questions and answers - Q: This is such a great overview of dbus.  I hadn't been paying attention to this space because it seemed to be in flux (10-15 years age).  How long has dbus been around and what was in place before that? - A: D-Bus dates to 2002, but really saw stabilization and adoption in the 2010s.  There wasn't really anything prior to D-Bus, you'd do some of the things it does by shelling out and driving command-line programs --- not a great approach. - Q: Forgive me if this question is silly: Why is everything dBus prefixed with "org."? - A: D-Bus services generally use reverse-FQDN notation, similar to Java packages, and most stuff using it is not-for-profit software, so `org.` is a very common prefix for those. - Q: In your investigations, do most OS/DE/WM interop well over d-bus? Which one(s) have proven more challenging, if any? - A: Since D-Bus is pretty uniform, DE/WM considerations aren't a large concern.  D-Bus isn't widely used on non-Linux systems, so OS differences have little to no impact. - Q: Re: using EXWM as a Desktop Environment -- Does EXWM provide a session manager (daemon)? - A: No, but it looks like it can work with external X11 session managers. - Q:There is a lot of critisism against d-bus out there, why do you think that might be? - A: Because it's not very good.  It uses XML, which isn't hip, and I think a lot of people have a knee-jerk negative reaction to. - Q: Which system services come to mind when thinking about applications, be it at the OS/DE/WM level? - A: Stuff that interacts with hardware: turning WiFi on and off, connecting to networks, pairing Bluetooth devices.  The kind of stuff you find in the upper-right of the dock/menubar in a traditional DE. - Q: "If you want to do the kinds of things that dBus does, you're limited": What is something dBus does that you couldn't do before? What is a really cool use of dBus in a modern DE (KDE/Gnome etc)? - A: D-Bus is fundamentally about making it *easier* to do things, and using that increased ease of use to broaden the number of places that kind of thing gets done.  So there's some prior art for doing some of these things, but none of them is as easy as doing it via D-Bus.  As far as specific features: I've been using computers a very long time, and it's still magic to me that you can just plug hardware in and immediately use it without having to do anything --- D-Bus is foundational to that kind of interactivity when it comes to things like storage, network, and Bluetooth-connected devices. - Q:  When it comes to managing devices, how are dBus and UDev related? - A: They're orthogonal.  I believe UDisks2 (which is the D-Bus service for managing disks) talks to UDev2, but this is abstract & not a detail you have to care about as a client of UDisks2. - Q: As an average GNU/Linux user, I've used signals and methods before but not properties. You gave an example involving properties, but it kind of flew by. Can you explain briefly what clients and services can do with properties? - A: Properties are metadata associated with an object interface[.   They can expose r/o information about the object (the name of the host; the UUID of a disk device; the hardware address of a network device), and you can modify certain properties about the object or service by writing to them.  For example, `org.freedesktop.NetworkManager.Device` has an `AutoConnect` property, which you can use to enable/disable automatic connection. - Q: what is the name of the dbus GUI you showed?  defeat? dfeet? - A: "d-feet"  - Q:  Naive Q (me not knowing much about dBus): Is there such a thing as a dBus reflection browser (maybe Emacs based) that lets you discover all the behavior different dBus app participants provide? Thinking something like what macOS Automator does? (actually, wait, think you're showing it) - A: d-feet is the one I showed: - I'd very much like something similar, but built into Emacs. - Q:dbus seems great for extensibility. But then Emacs has no such mechanism. And is fantastically more extensibile. Why do you think this is so?          - A: I think these are different kinds of extensibility.  Emacs is much more malleable than anything D-Bus offers.  You can't change how existing D-Bus services work in the same way as you can with Emacs customizations, variables, advice, or just going and hacking on the code live; you can only add new features by creating new services. - Q:  Do you have other cool dbus ideas? - A: I greatly want to see: - A D-Bus browser. - discomfort expanded and made better looking, so there isn't a single storage-related task I can't do with it and dired. - A NetworkManager interface, so I don't have to use nmtui/nmcli. - A Bluez (bluetooth) interface, so I never have to see bluetoothctl again. - Q: Are there Busses besides System and Session? Is there anything more to a Bus besides a way to group ~~services~~ objects? - A: There's always at least a System bus; theres one Session bus per logged-in session (so potentially zero).  You can create and connect to as many busses as you want, and they get identified by the socket they listen on, which can be a local UNIX socket or a TCP socket.  This isn't a common usecase, most things use system and session. - Q: It looks like dBus is mostly useful for Emacs to do IPC -- IIUC, this is how synctex works when working with LaTeX docs. How does it compare with other ways of doing IPC, for example, communicating over a socket with MPD? - A: D-Bus provides a uniform framework for building these services.  MPD's socket interface only works with MPD, and if you want to connect to one, you have to write code that speaks the protocol before you can do high-level things like "play" or "pause."  D-Bus provides the underlying communication layer as well as the model for the API, so you get all that stuff for free.  If a music player has a D-Bus interface, and you're using a language with D-Bus bindings, you can go from zero to "support playing and pausing" in one line of code. - Q: ~~What mainstream/popular d-bus alternatives have you seen out there, if any, maybe beyond pipes, udev, and such? -> somewhat redundant with the above~~ - A: There aren't any alternatives on Linux that I'm aware of.  Other operating systems have different ways of doing things similar to what D-Bus does (such as OSA/AppleScript on macOS). - Q: I see a python dbus tutorial, does it make sense to have an emacs version?   - A: That's a really good idea! - Q: How if at all do the various web browsers interop (well) via d-bus? - A: It could be better.  Firefox (and forks) have a simple interface that lets you open a URL, but nothing else.  I'm not sure about other browsers, since LibreWolf is what I use.  If you use d-feet to examine the session bus, you can see! - Q: Nice, thanks! I had been looking for a udisks tool. Is it available? - A: Yes, https://codeberg.org/emacs-weirdware/discomfort It's alpha, but way nicer than using udisksctl. Other discussions from IRC: - Very interesting talk Ian! - Pretty interesting... I am already scratching my head thinking on applications! - Thanks, fascinating ieure, now onto refactoring everything not yet into Emacs to be managed in Emacs via d-bus... - One usage example I've recently stumbled over is the scad-dbus package which can control the openscad gui from Emacs, move around the camera etc. - @ieure : Thanks for the great talk, love these expositions of yours, especially of things that have gone under-appreciated - and the packaging into timeless tunes obviously! [[!inline pages="internal(2022/info/dbus-after)" raw="yes"]] [[!inline pages="internal(2022/info/dbus-nav)" raw="yes"]]