The Socket as System Boundary
The Unix domain socket is the architectural boundary between bspwm and the rest of the system. Everything inside the socket is pure mechanism which includes :
- tree manipulation
- geometry calculation
- X event handling
- window state management
Everything outside the socket is pure policy which includes :
- when to manipulate the tree
- which geometries are desirable
- how to respond to events
- which windows should receive special treatment.
This boundary is absolute. There is no way to inject policy into bspwm without using the socket. There is no configuration option that changes bspwm’s core behavior. All configuration options set parameters for the mechanisms, like split_ratio or window_gap, but they do not implement policy logic. Policy lives in your keybinding daemon, your external rule script, your event subscribers, and your shell scripts.
The socket protocol is text-based and human-readable. You can manually connect to the socket using a tool like netcat or socat and type commands interactively. This makes debugging straightforward.
Tip
If a keybinding is not working, you can send the corresponding bspc command directly to verify that bspwm responds correctly. If an external rule is not firing, you can manually trigger the external rule command with test inputs.
The socket is also the reason bspwm can be controlled remotely. Any program on the system can connect to the socket and send commands. This enables integration with other tools.
There are endless possibilities with bspc socket
You could write a web interface that lets you control your window layout from a browser. You could build a voice-controlled interface that translates speech to bspc commands. You could implement automatic window management based on signals from other applications, like tiling development tools when you open a compiler or focusing communication apps when someone messages you.
bspwm does not care where commands come from. It only cares that they are syntactically valid messages that specify operations on its tree. This is the ultimate expression of mechanism-policy separation: the mechanism is locked inside the socket boundary, and policy is whatever you choose to implement outside it.