summaryrefslogtreecommitdiffstats
path: root/2022/talks/dbus.md
blob: 78500f100574baeb4ea4f73cbc56a362bbfbe13b (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
[[!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"]]

[[!template id="help" 
volunteer=""
summary="Q&A could be indexed with chapter markers"
tags="help_with_chapter_markers"
message="""The Q&A session for this talk does not have chapter markers yet.
Would you like to help? See [[help_with_chapter_markers]] for more details. You can use the vidid="dbus-qanda" if adding the markers to this wiki page, or e-mail your chapter notes to <emacsconf-submit@gnu.org>."""]]

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"]]