[[!sidebar content=""]]
[[!meta title="The Wheels on D-Bus"]]
[[!meta copyright="Copyright © 2022 Ian Eure"]]
[[!inline pages="internal(2022/info/dbus-nav)" raw="yes"]]
<!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing -->
<!-- You can manually edit this file to update the abstract, add links, etc. --->
# 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
- - <https://codeberg.org/emacs-weirdware/debase>
- <https://codeberg.org/emacs-weirdware/discomfort>
- 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:
<https://wiki.gnome.org/Apps/DFeet>
- 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?
<https://dbus.freedesktop.org/doc/dbus-python/tutorial.html>
- 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:
- A:
[[!inline pages="internal(2022/info/dbus-after)" raw="yes"]]
[[!inline pages="internal(2022/info/dbus-nav)" raw="yes"]]
