#i3 #ipc #protocol #json #serde

i3ipc-types

Library containing all the types needed to communicate with i3, along with their serde implementations and implementations of many std traits

8 breaking releases

0.12.0 Jan 11, 2021
0.11.0 Nov 2, 2020
0.10.0 Aug 21, 2020
0.9.0 Jul 1, 2020
0.5.0 Apr 21, 2019

#39 in GUI

Download history 15/week @ 2020-12-22 19/week @ 2020-12-29 46/week @ 2021-01-05 47/week @ 2021-01-12 57/week @ 2021-01-19 36/week @ 2021-01-26 28/week @ 2021-02-02 37/week @ 2021-02-09 108/week @ 2021-02-16 36/week @ 2021-02-23 38/week @ 2021-03-02 33/week @ 2021-03-09 22/week @ 2021-03-16 56/week @ 2021-03-23 55/week @ 2021-03-30 41/week @ 2021-04-06

174 downloads per month
Used in 6 crates (3 directly)

MIT license

27KB
689 lines

i3ipc-types

Crate API

This crate includes all the types for interacting with i3ipc, along with some undocumented properties I found by browsing i3's source code. It also includes some basic sway support, though I don't personally use sway so I'm relying on PRs to maintain this feature.

This crate includes the definitions for all i3 ipc message responses, event types, and serialize/deserialize implementations using serde. Additionally, I've included traits with default implementations for encoding and decoding for speaking i3's ipc protocol, so long as the type has implemented io::Read and io::Write.

My goal is to locate all of the type definitions for i3's IPC implementation here, so no one ever has to go through the tedium again. If anything is missing or not working, please fill out an issue or submit a PR, I'm happy to fix things or improve the library in any way I can.

Features

By default this crate will include features for synchronous IO. Using stds io::Read + io::Write

If async-traits is enabled, I3Protocol will be implemented for any trait that implements tokio's AsyncRead + AsyncWrite

Advantages over i3ipc-rs

i3ipc-rs packs the event responses into a single enum, this is wasteful if you intend to receive responses to events for anything except workspaces & windows, since there is no indirection in the type definiton. Rust's memory layout for enums makes each variant take up to the size of the largest variant, that means that responses with relatively few fields like OutputData would take up as much space as WindowData. In this crate, that's not the case. There's a layer of indirection for WorkspaceData and WindowData so that the minimum variant size remains small.

Dependencies

~0.8–3.5MB
~74K SLoC