4 releases (stable)

new 25.5.0 May 17, 2025
25.2.0 Feb 25, 2025
25.1.0 Jan 11, 2025
0.1.10 Nov 9, 2024

#538 in GUI

Download history 81/week @ 2025-01-25 48/week @ 2025-02-01 80/week @ 2025-02-08 53/week @ 2025-02-15 140/week @ 2025-02-22 56/week @ 2025-03-01 29/week @ 2025-03-08 49/week @ 2025-03-15 39/week @ 2025-03-22 21/week @ 2025-03-29 37/week @ 2025-04-05 43/week @ 2025-04-12 43/week @ 2025-04-19 85/week @ 2025-04-26 75/week @ 2025-05-03 45/week @ 2025-05-10

252 downloads per month
Used in 3 crates

GPL-3.0-or-later

69KB
1K SLoC

niri-ipc

Types and helpers for interfacing with the niri Wayland compositor.

Backwards compatibility

This crate follows the niri version. It is not API-stable in terms of the Rust semver. In particular, expect new struct fields and enum variants to be added in patch version bumps.

Use an exact version requirement to avoid breaking changes:

[dependencies]
niri-ipc = "=25.5.0"

lib.rs:

Types for communicating with niri via IPC.

After connecting to the niri socket, you can send Requests. Niri will process them one by one, in order, and to each request it will respond with a single Reply, which is a Result wrapping a Response.

If you send a Request::EventStream, niri will stop reading subsequent Requests, and will start continuously writing compositor Events to the socket. If you'd like to read an event stream and write more requests at the same time, you need to use two IPC sockets.

Requests are always processed separately. Time passes between requests, even when sending multiple requests to the socket at once. For example, sending Request::Workspaces and Request::Windows together may not return consistent results (e.g. a window may open on a new workspace in-between the two responses). This goes for actions too: sending Action::FocusWindow and Action::CloseWindow { id: None } together may close the wrong window because a different window got focused in-between these requests.

You can use the socket::Socket helper if you're fine with blocking communication. However, it is a fairly simple helper, so if you need async, or if you're using a different language, you are encouraged to communicate with the socket manually.

  1. Read the socket filesystem path from socket::SOCKET_PATH_ENV ($NIRI_SOCKET).
  2. Connect to the socket and write a JSON-formatted Request on a single line. You can follow up with a line break and a flush, or just flush and shutdown the write end of the socket.
  3. Niri will respond with a single line JSON-formatted Reply.
  4. You can keep writing Requests, each on a single line, and read Replys, also each on a separate line.
  5. After you request an event stream, niri will keep responding with JSON-formatted Events, on a single line each.

Backwards compatibility

This crate follows the niri version. It is not API-stable in terms of the Rust semver. In particular, expect new struct fields and enum variants to be added in patch version bumps.

Use an exact version requirement to avoid breaking changes:

[dependencies]
niri-ipc = "=25.5.0"

Features

This crate defines the following features:

  • json-schema: derives the schemars JsonSchema trait for the types.
  • clap: derives the clap CLI parsing traits for some types. Used internally by niri itself.

Dependencies

~0.6–1.7MB
~35K SLoC

OSZAR »