IPC
i3 has an IPC interface (it creates a socket that applications can connect to and issue commands or queries via its protocol), and sway replicates that protocol (so e.g. i3-msg can be used with sway by simply changing the socket, e.g. i3-msg -s $(sway --get-socketpath)). The code for that lies in sway/ipc.
No D-Bus in this day and age?
(not to undermine the otherwise impressive achievement, I was just a little surprised about this little backward bit. But then, I guess it's required for compatibility?)
Not using dbus for its ipc is a feature of i3 for me. What it has works perfectly compared to every interaction I've ever had with dbus, which is always pain.
Yeah i can't help wonder if dbus is one contribution element to making bluetooth painful on Linux.
This because the tray side client talks to the daemons over dbus to get anything done. And i have seen file transfer after file transfer get lost in dbus limbo.
By this i mean that i initiate a transfer from pc to phone via the gui. Everything checks out on both ends, but no data gets transferred.
So i hit abort, and try over, but now nothing happens at all.
And no restarting of the relevant daemons or clients change a thing.
Only by restarting dbus, and thus restarting my desktop along with it, will i be able to initiate a new file transfer (that may again get stuck in limbo).
i3 explicitly had a IPC interface separate from D-Bus:
"Implement an IPC interface for other programs. Provide subscription to certain events and accept commands.
This approach should be more lightweight than wmii’s usage of the 9P filesystem. Furthermore, core functionality does not depend on a separate program, so that i3 runs faster, especially when your system is under load."
https://i3wm.org/
(not to undermine the otherwise impressive achievement, I was just a little surprised about this little backward bit. But then, I guess it's required for compatibility?)