I3_client - i3 IPC client, written in Erlang

krasenyp

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:

6 comments

#library #gui #i3 #sway

10 592 6

2026-03-06 19:05:51 UTC

Showing Posts 6 to 1

Show Best Posts
Show All (oldest first)
Show All (newest first)

krasenyp

I’m happy to announce that v0.3.0 was just released.

This version brings a new module - i3_client_trees which includes functions for processing i3 layout trees. Currently, it holds only two functions - table/1,2. The functions return QLC handle which allows for iterator style traversal. For example, you can very easily find the focused node:

0> QH = qlc:q([Node || #{~"focused" := true} = Node <- i3_client_trees:table(Tree)]),
1> [#{~"focused" := true}] = qlc:eval(QH).

Post #6

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.

Post #5

MaxRu

Very cool! How do you render the status bar to the screen? I also do have a self built status bar but currently its in python and uses gtk bindings.

From my search i did not find a great way to render this with the beam.

Post #4

krasenyp

I’m using the client in two places. One is my own S atstatus bar because I daily drive FreeBSD and most status bars don’t work.

The other is an integration daemon. I intercept Sway commands and, for example, depending on the currently focused window I handle the commands differently.

Post #3

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?

Post #2

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.

Post #1

— All posts loaded —