krasenyp
I3_client - i3 IPC client, written in Erlang
This is an i3 IPC client implementation, written in Erlang, with zero dependencies. All the messages and events exposed by i3 and Sway are currently supported.
It’s a very early release but it’s fully featured. My next two priorities are improving the test coverage and extending the documentation with examples. Nevertheless, I’ll be happy to hear from early users.
Notable features
- Variant negotiation - rudimentary capability checks but the fundamentals are ther
- Automatic reconnection - opt-in but nice to have
- Multiplexing - a single connection can handle request-response and out-of-band events.
Example
The following example shows how to start a client connection, subscribe to events and run commands. All using the same connection, all idiomatic OTP behaviour.
iex> {:ok, pid} = :i3_client.start_link([])
iex> {:ok, ref} = :i3_client.subscribe(pid, ["window"])
iex> {:ok, _} = :i3_client.run_command(pid, "focus right")
iex> flush()
{:i3_event, ^pid, ^ref, "window", "..."} # Pseudocode but you get the idea
Hex: i3_client | Hex
Source:
Most Liked
krasenyp
I’m happy to announce that v0.2.0 was just released.
This version brings one user-facing change - first tick events, the ones received right after a subscription to tick events is made, are treated as unicast events. They used to be broadcast events, like any other type of event, but it was an incorrect behaviour. I knowingly left it that way in the initial version because it was tolerable but now it’s time for correct and predictable handling of this special kind of event.
MaxRu
Very cool stuff!
I’m currently also working on a client like this but for wayland protocols because i am building a WM in elixir.
Whats your use case for an i3 client in erlang?
krasenyp
Nothing special on my side, I’m just using the swaybar protocol. I use i3_client to keep track of various pieces of state. For example, I’m subscribed to input events and update the bar accordingly whenever I change the keyboard layout.







