# egui_crates: the egui widgets Rerun maintains in one workspace

> This monorepo holds the egui crates that Rerun develops and uses in its own product: a tiling layout engine, a table widget for very large row counts, an MCP server that lets agents drive egui apps, and a test inspector. Three of the five are published to crates.io, and the workspace pins egui 0.37 with one deliberate exception.

**rerun-io/egui_crates** — A monorepo for egui crates used within and maintained by rerun

- Repository: https://github.com/rerun-io/egui_crates
- Website: https://rerun-io.github.io/egui_crates/
- Stars: 595 · Forks: 60
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/rerun-io-egui-crates

## Five crates, three of them published

The repository is described as a monorepo of all the egui crates that Rerun maintains and uses within rerun. The table at the top of the README lists five crates and, usefully, marks which ones are actually published.

egui_tiles is a tiling layout engine with drag-and-drop and resizing, and it is published to crates.io. egui_table is a table widget for millions of rows, also published. egui_mcp lets agents control and inspect egui apps, and it is published too.

The other two are marked as not published. egui_table_demo is the web demo for egui_table, and kittest_inspector is a UI to inspect and control egui apps and tests.

That distinction is the most useful thing in the table, because it tells you what you can depend on from crates.io and what is development scaffolding. The demo exists to run the table in a browser, and the inspector is tooling for the test harness, so neither is meant to be consumed as a library.

The recent releases confirm the pattern. egui_tiles 0.18.0, egui_table 0.11.0 and egui_mcp 0.3.0 were all published on 2026-10-19, and each release title names the egui version it targets, egui 0.37. Three separate version lines, all released on the same day, each pinned to a specific egui release.

The licences are dual, MIT OR Apache-2.0, and development is sponsored by Rerun, described as an easy-to-use database and visualization toolbox for multimodal and temporal data. The last push to the repository was on 2026-10-19, the same day as those releases, so the crate lines and the repository move together even though the versions are independent.

## The workspace layout and the version floor it imposes

The Cargo.toml at the root defines a workspace with five members and resolver version 3, and the shared package settings are minimal but consequential:

```toml
[workspace.package]
edition = "2024"
license = "MIT OR Apache-2.0"
rust-version = "1.95.0" # The highest MSRV of the crates in this repo
```

That comment on the rust-version line is the whole story. The workspace MSRV is not the lowest requirement among the crates, it is the highest, because the workspace has to compile every member with a single toolchain. If one crate needs 1.95.0, everyone in the workspace needs 1.95.0, and that is a floor you inherit even if you only depend on one of them.

Edition 2024 is worth noting as well, since it is a recent edition and constrains what language features the crates can use.

The member list shows the shape of the repository, with the crates directory holding egui_mcp, egui_table, egui_table_demo, egui_tiles and kittest_inspector. Everything else in the root supports that set: a check.sh script, a clippy.toml for lint configuration, a deny.toml for cargo-deny, a lychee.toml for link checking, a rust-toolchain file that pins the toolchain for the workspace, a .mcp.json at the root, a .typos.toml for spell checking, RELEASES.md and the scripts directory.

The tooling list is a decent signal of the project's maturity. A workspace that maintains a deny configuration, a link checker and a typo checker is a workspace that expects to be depended on.

## Why egui is deliberately absent from the workspace dependencies

The most interesting thing in the Cargo.toml is a set of comments explaining what is not there, and the reason is a genuine technical constraint rather than an oversight.

The comment states that egui itself is deliberately not in the workspace dependencies. The reason given is that kittest_inspector rides the lucas/kittest-inspect branch of egui, using the old inspector_api protocol, while every other crate uses the released egui 0.37 with the new egui_inspection protocol. Because the two use different inspection protocols, they cannot share one entry.

So the workspace dependencies list the released versions:

```toml
eframe = { version = "0.37.0", default-features = false }
egui = { version = "0.37.0", default-features = false }
egui_inspection = { version = "0.37.0", default-features = false }
egui_kittest = { version = "0.37.0" }
```

And crates/kittest_inspector names its git dependencies itself, pointing at the branch rather than the registry.

The AccessKit entries carry their own constraint comments. accesskit is declared with the enumn feature, and the comment says enumn gives Role::n, used to validate a role string against the full AccessKit role set. Both accesskit and accesskit_consumer carry the note that the version must match the accesskit version egui uses, which is the kind of comment that saves an afternoon of a version mismatch error.

For a user of these crates, the practical consequence is that egui_tiles, egui_table and egui_mcp are ordinary crates.io dependencies on released egui 0.37, and only the test inspector is pinned to an unpublished branch. If you are not running the inspector, you are unaffected by that decision.

## The two developer-facing crates, and what they are for

egui_tiles and egui_table are the two crates with a broad audience, and they solve two problems that recur in every desktop application built with egui.

egui_tiles is a tiling layout engine with drag-and-drop and resizing. In an immediate mode GUI, a window system has to be built, and a tiling model is the one many developer tools use, where panels are arranged in a grid rather than floating independently. A crate that provides that, with drag and drop and resizing already handled, is a substantial amount of interaction logic to not have to write.

egui_table is a table widget for millions of rows. The scale qualifier is the point, since a naive table widget that instantiates a widget per row does not work at that size and needs a virtualised approach instead. The fact that Rerun needed this for its own visualisation and backup tooling is a reasonable signal that the requirement is real.

The demo crate exists to exercise the table in a browser, which is a sensible way to test a widget with very large data sets, since generating millions of rows in a browser is trivial compared to doing it in a real application. The egui_table_demo is not published, so it is a development tool rather than something you would depend on.

The third published crate, egui_mcp, is the interesting one for anyone working on tooling for AI agents. It lets agents control and inspect egui apps. The dependency list shows how that is done: rmcp at version 3.5 with the server, macros, transport-io and schemars features, plus schemars 1.2 for schema generation. The MCP server and the transport features are what turn the crate into a server an agent can talk to.

The inspector crate, kittest_inspector, is the fourth: a UI to inspect and control egui apps and tests, which pairs with egui_kittest, the test harness, at version 0.37.0.

## What the repository does not tell you, and what to check first

The README is short, deliberately so, and that means some questions a new user would ask are answered elsewhere or not at all.

There is no usage documentation in the README. Each crate has its own documentation site, and the crate pages on crates.io are the place to look for API documentation and examples. The homepage for the monorepo is a generated documentation site at rerun-io.github.io/egui_crates/, which suggests the docs are built from the source comments rather than written separately.

The release process is documented in RELEASES.md, and given that three crates ship on independent version lines, that file is the one to read to understand what a version bump means for a given crate. The fact that release titles carry the egui version they target, as in egui_table 0.11.0 with egui 0.37, tells you that the egui version is part of the compatibility story and not an implementation detail.

Two things to weigh before depending on these crates. The first is the MSRV floor of 1.95.0, which the workspace sets to the highest requirement in the repo. If your project targets an older stable Rust, you are blocked by the workspace floor even if the specific crate you want would compile on an older toolchain.

The second is the sponsorship arrangement. Development is sponsored by Rerun because these crates are used within their product, which is a healthy arrangement for a dependency, and it also means the roadmap follows what Rerun needs. That is fine if your needs overlap, and it is a reason to read the changelog before upgrading rather than assuming semver compatibility covers the egui version jump.

Finally, the crates are individually published, so you take a dependency on egui_table 0.11.0, not on this monorepo. The repository is where the code lives, not something you install.

## Conclusion

Adopt egui_tiles or egui_table if you are building an egui application that needs a tiling layout or a table over millions of rows, and take egui_mcp if you want an agent to drive and inspect your egui app through the Model Context Protocol. Do not expect the whole workspace to be uniform, because kittest_inspector deliberately rides a git branch of egui rather than the released 0.37, so its dependency story differs from the other crates. Before you add any of them, check the MSRV, which the workspace sets to 1.95.0 because of the highest requirement in the repo, and read the RELEASES.md file, since the release lines move independently of the egui versions they build against.

## FAQ

### Which egui crates does egui_crates publish to crates.io?

Three: egui_tiles, the tiling layout engine with drag-and-drop and resizing, egui_table, the table widget for millions of rows, and egui_mcp, which lets agents control and inspect egui apps. The table demo and the kittest inspector are not published.

### What Rust version do the egui_crates require?

The workspace sets rust-version to 1.95.0, with a comment noting it is the highest MSRV of the crates in the repo. The workspace edition is 2024 and the licence is MIT OR Apache-2.0.

### Why is egui not listed in the workspace dependencies?

The Cargo.toml comment explains it: kittest_inspector rides the lucas/kittest-inspect branch of egui with the old inspector_api protocol while every other crate uses the released egui 0.37 with the new egui_inspection protocol, so the two cannot share one entry. The inspector names its git dependencies itself.

### What does egui_mcp do?

It lets agents control and inspect egui apps. Its dependencies include rmcp at version 3.5 with the server, macros, transport-io and schemars features, and schemars 1.2 for schema generation, which is what makes it usable as a Model Context Protocol server.

### How are the egui_crates versions related to egui releases?

Each crate has its own version line, and the release titles name the egui version they target, for example egui_table 0.11.0 with egui 0.37. RELEASES.md in the repository records the release history.

## Sources

- [License: Apache-2.0](https://github.com/rerun-io/egui_crates/blob/main/LICENSE)
- [Project website](https://rerun-io.github.io/egui_crates/)
- [README](https://github.com/rerun-io/egui_crates/blob/main/README.md)
- [Releases](https://github.com/rerun-io/egui_crates/releases)
- [rerun-io/egui_crates on GitHub](https://github.com/rerun-io/egui_crates)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rerun-io-egui-crates