Crate i3_ipc

Expand description

i3-ipc

Subscribing to events is easy:

use i3_ipc::{
    event::{Event, Subscribe},
    I3Stream,
};
use std::io;

fn main() -> io::Result<()> {
    let mut i3 = I3Stream::conn_sub(&[Subscribe::Window, Subscribe::Workspace])?;
    for e in i3.listen() {
        match e? {
            Event::Workspace(ev) => println!("workspace change event {:?}", ev),
            Event::Window(ev) => println!("window event {:?}", ev),
            Event::Output(ev) => println!("output event {:?}", ev),
            Event::Mode(ev) => println!("mode event {:?}", ev),
            Event::BarConfig(ev) => println!("bar config update {:?}", ev),
            Event::Binding(ev) => println!("binding event {:?}", ev),
            Event::Shutdown(ev) => println!("shutdown event {:?}", ev),
            Event::Tick(ev) => println!("tick event {:?}", ev),
        }
    }
    Ok(())
}

Getting information is equally easy, use any get_* method or run_command to send a message to i3:

use i3_ipc::{Connect, I3};
use std::io;

fn main() -> io::Result<()> {
    let mut i3 = I3::connect()?;
    let workspaces = i3.get_workspaces()?;
    println!("{:?}", workspaces);
    Ok(())
}

For subscribing and receiving events, each struct matches a particular Subscribe variant. For instance, subscribing with Subscribe::Workspace will net Event::Workspace when workspace events are sent over the ipc.

msg

For sending messages to i3

reply

Contains structs for deserializing messages from i3

Structs

I3

Our connection type, we implement Connect for this

I3Iter

I3 event iterator, after you’re subscribed to events (with the subscribe method). The iterator will advance each iteration on receiving an Event. These are decoded using serde_json and returned

I3Stream

I3Stream will hold the underlying UnixStream that communicates with i3

MsgResponse

Instead of returning an enum, we’re returning a struct containing the Msg type and some body. An advantage to this over the enum method is that there is no minimum memory size that we must have. This is helpful when some variants are very large compared to others, as in the case of say reply::Node vs reply::Config