diff options
Diffstat (limited to '2022/talks/dbus.md')
| -rw-r--r-- | 2022/talks/dbus.md | 144 |
1 files changed, 144 insertions, 0 deletions
diff --git a/2022/talks/dbus.md b/2022/talks/dbus.md index 58da6224..5d944ad8 100644 --- a/2022/talks/dbus.md +++ b/2022/talks/dbus.md @@ -16,6 +16,150 @@ 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"]] |