Events IPC

[mentalblock]

I would like to suggest a separate, read-only Events IPC socket. This is something that the Hyprland compositor provides.

All events can be monitored by watching this socket. This would allow bars that have no plans to implement Wayland protocols to retrieve status changes immediately and efficiently. In particular, Eww is the bar I currently use. It has a listening mechanism, deflisten, that monitors the output of a command and updates the bar UI.

In summary, if Niri had a read-only Events IPC, I would then be able to use the socat utility to extract and parse whatever Niri state I would like. It is lightweight and responsive method. My only use case at the moment is for workspaces status and focused window titles, but I am sure others would leverage this to suit their needs.

Related discussions and issues:

• IPC for getting information about niri #209
• Implement ext-workspace #135

[YaLTeR]

Why a separate socket? My plan is to just make a niri msg event-stream (or something) that sends you events indefinitely.

[morenathan]

@nebulosa2007 Same issue I have with almost all actions. I'm not really sure how the current event system is of any use without communication.

[mentalblock]

Why a separate socket? My plan is to just make a niri msg event-stream (or something) that sends you events indefinitely.

A possible downside of running a separate process is that it may seem unnecessary friction when the alternative could be to just open a file (socket) when programmatically trying to interact with Niri

[YaLTeR]

All niri msg is doing is opening a socket and writing a json message. No problem doing that manually.

[mentalblock]

I am not sure I understand what you mean. In the context of a separate, read-only socket I proposed here, you asked if there was any reason for such a proposal if you were already creating something like niri msg event-stream. At first I could not think of anything.

I then realized that if someone wanted to programmatically monitor events from Niri, running a separate process such as niri msg event-stream may be more cumbersome than reading a file (socket). This is all I meant. When you reply about writing a JSON message, I feel that we have maybe misunderstood each other as monitoring events from a separate Events IPC socket would have nothing to do with writing JSON messages.

[YaLTeR]

niri msg event-stream is (will be) equivalent to connecting to $NIRI_SOCKET, writing a json message there, then just reading events. Which is not that much harder than connecting to a (second proposed) socket and reading events. There's only one extra step (writing a json message) of difference between the two.

[YaLTeR]

It's implemented now: https://github.com/YaLTeR/niri/wiki/IPC#event-stream

[salahoued]

Hi, I just started using niri, and I use eww as a status/widgets bar, I have made my eww config to work with hyprland ans labwc to show the workspaces, active windows and keyboard layout (using 2 layouts), but I still can't wrap my head around the way to make it work with niri.

this is how I get workspaces on hyprland (from its wiki)

#!/usr/bin/env bash

spaces (){
  WORKSPACE_WINDOWS=$(hyprctl workspaces -j | jq 'map({key: .id | tostring, value: .windows}) | from_entries')
  WORKSPACE_NUMBER=$(echo "$WORKSPACE_WINDOWS" | jq '. | length')
  seq 1 "$WORKSPACE_NUMBER" | jq --argjson windows "${WORKSPACE_WINDOWS}" --slurp -Mc 'map(tostring) | map({id: ., windows: ($windows[.]//0)})'
}

spaces
socat -u UNIX-CONNECT:$XDG_RUNTIME_DIR/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock - | while read -r line; do
  spaces
done

is there any way to adapt it to work with niri

Thanks for all your hard work.

[YaLTeR]

Everything you mentioned is possible (Waybar implements it for example). This discussion has a bunch of examples for workspaces: #356

[roceb]

You can use niri msg windows | grep windows-id | wc -l

…

On Mon, Jun 16, 2025, 2:22 AM Ivan Molodetskikh ***@***.***> wrote: Everything you mentioned is possible (Waybar implements it for example). This discussion has a bunch of examples for workspaces: #356 <#356> — Reply to this email directly, view it on GitHub <#411 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFC4R2VE2EB6CDFWLYC3BD33DZPBNAVCNFSM6AAAAAB7LWI222VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNBXHEZDOMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>