# i3status-rust: a Rust replacement for the i3 status bar engine

> A pure Rust rewrite of i3status that talks the i3bar protocol, ships dozens of configurable blocks, is distributed through distribution packages rather than cargo, and was last pushed to on 2026-09-07.

**greshake/i3status-rust** — Very resourcefriendly and feature-rich replacement for i3status, written in pure Rust

- Repository: https://github.com/greshake/i3status-rust
- Stars: 3,150 · Forks: 520
- Language: Rust
- License: GPL-3.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/greshake-i3status-rust

## What the project actually replaces

i3status-rs is a from-scratch implementation of the status line process that i3bar expects, written in pure Rust and described by its own description as a resource-friendly replacement for i3status. It does not replace i3bar itself. The bar, the window management, the keybindings and the workspace model all stay exactly where they are. What changes is the process i3bar spawns to feed bar content, and that process is i3status-rs instead of the C i3status binary.

The interface between the two is the i3bar protocol, which is a documented, line oriented JSON format. Any bar that speaks that protocol can host i3status-rs, which is why the README describes the project as providing a way to display blocks of system information on bars that support the i3bar protocol. The word blocks is the central idea in the design. A configuration is a list of blocks, each responsible for one piece of information: time, battery, volume, disk usage, and a long tail of others. Each block decides its own update cadence and its own presentation, and the bar process does not need to know how any of that works.

The repository is GPL-3.0, declared in Cargo.toml as GPL-3.0-only, which matters if you intend to ship it inside a product with a different license. It is a real Rust project in the modern sense: edition 2024, a Cargo workspace whose members are the main crate and an xtask helper, a lock file, and a set of repository level quality gates including rustfmt.toml, clippy.toml, cspell.yaml and a pre-commit configuration. Version 0.36.1 is what Cargo.toml declares, matching the most recent published release.

## Where the binaries come from

Distribution is the first thing to sort out, because this project does not hand you a tarball and it does not want you to build from source with cargo. The installation section is unusually direct about that: installation via cargo is not supported. That single line removes the most obvious first attempt, and it is worth understanding why the guidance exists. i3status-rs talks to a fair amount of host specific machinery, so the shipped packages bundle the system libraries each block family needs, and a generic cargo build would not reproduce that set.

What you get instead is a set of packaging channels. A Repology badge tracks how many repositories carry a version of i3status-rust, which is the fastest way to answer whether your distribution has it at all. For Fedora and CentOS the README points at a community supported COPR. For NixOS there is a Home Manager option, enabled with a single boolean, and the Home Manager documentation lists the additional options that come with it. Everything else is directed to a manual install guide kept in the repository under doc/manual_install.md.

The practical consequence is that i3status-rs is a package-manager decision before it is a configuration decision. If your distribution carries it, installation is uneventful and the rest of this article is what matters. If it does not, you are reading a build guide and assembling dependencies yourself, and the effort involved is far larger than the size of the project suggests.

## Configuration layout and the global knobs

Configuration is a TOML file. After installing, you edit the example configuration shipped in the repository at examples/config.toml and place the result at $XDG_CONFIG_HOME/i3status-rust/config.toml. The project treats that example file as the reference: the README does not enumerate the available blocks, it points at the generated block documentation for the current release and at the equivalent documentation built from the master branch, so the example file and the docs are the two places to look.

A handful of settings are global rather than per block, and they sit either at the top level or inside a TOML table. Icons are controlled by an icons key inside an icons table, naming the icon set to use, defaulting to none, with a nested table for per-icon overrides. Themes work the same way through a theme table, defaulting to plain. Both are documented in doc/themes.md, which is linked from the README for both master and for the pinned 0.32.0 tag.

The remaining global variables cover formatting and failure display. icons_format is the string used to wrap each icon, and its default of a space, the icon, a space is a reasonable starting point for most setups; the README shows how the same setting can carry a span with a specific font family so that icon glyphs resolve separately from surrounding text. invert_scrolling flips scroll direction, which matters on touchpads. error_format and error_fullscreen_format control how failures appear, each with a default string and each accepting either the full error message or the short form as a placeholder. That is a small surface, deliberately so, since everything else in the file belongs to individual blocks.

## Wiring the bar to the new status command

The integration step is short. Point the bar at the i3status-rs binary and pass it your config path as an argument. The font declaration matters as much as the status command, because blocks can reference icon glyphs that only resolve if the icon font is in the list.

```text
bar {
    font pango:DejaVu Sans Mono, FontAwesome 12
    position top
    status_command path/to/i3status-rs path/to/your/config.toml
    colors {
        separator #666666
        background #222222
        statusline #dddddd
        focused_workspace #0088CC #0088CC #ffffff
        active_workspace #333333 #333333 #ffffff
        inactive_workspace #333333 #333333 #888888
        urgent_workspace #2f343a #900000 #ffffff
    }
}
```

The FontAwesome name in that example is the part most likely to need changing on a current system. The README flags that the font name changed in version 5 and later, and gives you two commands to find the truth on your own machine. The first resolves a name to whatever fontconfig will actually load for it.

```shell
$ fc-match FontAwesome
fontawesome-webfont.ttf: "FontAwesome" "Regular"
```

The second lists the installed families so you can pick the exact name.

```shell
$ fc-list | grep -i awesome
/usr/share/fonts/TTF/fa-solid-900.ttf: Font Awesome 5 Free,Font Awesome 5 Free Solid:style=Solid
/usr/share/fonts/TTF/fa-regular-400.ttf: Font Awesome 5 Free,Font Awesome 5 Free Regular:style=Regular
```

With a version 5 family installed, the font parameter would use Font Awesome 5 Free instead. Once the bar block is in place, reloading i3 is a single command, and the README points at a long standing issue thread where the same font naming problem is discussed in detail.

## Block states, error handling and signals

Every block carries a state that determines its color, and the set is fixed: Idle, Info, Good, Warning, Critical and Error. The state is not something you set. Each block decides it from its own logic, and the README gives the music block as the illustration, where the state is Info while a player is active. The practical effect is that you get severity coloring for free without writing threshold logic, and that two blocks showing different states read differently at a glance.

Failures are handled inside the same model. When a block enters the Error state it shows a short error message in place of its normal output. Clicking the block toggles to the full error message, and that click overrides any click actions defined in the configuration for that block, which is a sensible priority when something is broken. The block is then restarted once error_interval has elapsed, so a transient failure recovers on its own instead of leaving a dead segment in the bar.

Signals cover the cases where you want the process to react from outside. Sending SIGUSR1 forces an update of every block, which is the hook to use from a keybinding when you have just changed something you want reflected immediately. Sending SIGUSR2 restarts the process in place, which the README specifically recommends when you are testing configuration edits. There is a third case, and it comes from i3bar rather than from you: i3bar pauses the bar with SIGSTOP when the bar is hidden or obscured by a fullscreen container, and that power saving behaviour has caused reported problems. Starting i3status-rs with the --never-stop argument changes the signal i3 sends from SIGSTOP to SIGCONT, which sidesteps the issue. For diagnosis, run the binary in a terminal to see the JSON it emits, and enable per block logging with RUST_LOG set to the block name at debug level.

## Build layout, optional features and release pace

The Cargo manifest is worth reading if you ever need to build this yourself. The default feature set is pulseaudio, which pulls in the PulseAudio bindings, and the optional features cover the alternatives and extras: pipewire for PipeWire sessions, notmuch for mail indexing, maildir for maildir-based mail checks, icu_calendar for locale aware calendar handling, and debug_borders, which draws borders around block output and is exactly what you want when you are working out why a block is rendering where it is. The workspace declares two members, the main crate and xtask, and the repository root carries build.rs, install.sh, a verify_icon_files.sh script and a gen-screenshots directory alongside doc, examples, files and testdata.

Release activity is steady rather than rapid. Version 0.36.1 was published on 2026-03-27, 0.36.0 on 2026-03-08, and 0.35.0 on 2025-12-15. The release notes themselves are not carried in the release bodies, which simply point at NEWS.md in the repository, and there is a release-process.md file at the root. The most recent push landed on 2026-09-07. With 3,150 stars, 520 forks and 125 open issues, the open issue count is large enough that searching it before you file anything is usually worthwhile, since font naming, block behaviour and packaging questions have almost certainly been raised already.

## Conclusion

i3status-rs makes sense for anyone already running i3 or sway who wants a status engine with more blocks, finer theming and less work per update cycle than the C original provides. Read it as a replacement rather than an add-on: you point i3bar at a different status_command and rewrite your configuration in TOML, so the migration cost is the config, not the code. Check three things before committing. Whether your distribution actually carries the package, since the project publishes no binaries and the Fedora build lives in a COPR. Whether the blocks you care about exist in the form you need, because the feature list is wide but each block still has its own options. And whether your font situation matches the icon set you intend to use, since the Font Awesome naming changed in version 5 and the README spends real space on it. If you only need a clock and a battery reading, the stock i3status is still the shorter path.

## FAQ

### Can i3status-rs be installed with cargo install?

No, and the README says so directly: installation via cargo is not supported. Packages come through distribution channels such as a Repology-tracked repository, a community supported COPR on Fedora and CentOS, or Home Manager on NixOS, which is enabled with a single boolean option. For anything else, the repository keeps a manual install guide under doc/manual_install.md.

### Where does the i3status-rs configuration file live?

The default path is $XDG_CONFIG_HOME/i3status-rust/config.toml. The file format is TOML, and the reference version shipped in the repository is examples/config.toml, which the README points you at as the thing to edit. Global settings such as the icon set, the theme, icons_format, invert_scrolling and the two error format strings can sit at the top level or inside the icons and theme tables.

### Why do my Font Awesome icons not show up on the i3status-rs bar?

The font name in your bar configuration has to match a family that fontconfig can actually resolve, and the README notes that the name changed in Font Awesome version 5 and later. Run fc-match against the name you used and run fc-list filtered for awesome to see the families installed on your machine, then put the matching name into the font parameter of your bar block. The README links a long running issue thread on the same topic.

## Sources

- [greshake/i3status-rust on GitHub](https://github.com/greshake/i3status-rust)
- [Issues](https://github.com/greshake/i3status-rust/issues)
- [License: GPL-3.0](https://github.com/greshake/i3status-rust/blob/master/LICENSE)
- [README](https://github.com/greshake/i3status-rust/blob/master/README.md)
- [Releases](https://github.com/greshake/i3status-rust/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/greshake-i3status-rust