egui_dock: a docking system for the egui immediate-mode GUI

A docking model for a library that had none

egui_dock is a docking system for egui, the immediate-mode GUI library for Rust. The README describes it as originally created by @lain-dono, and the crate metadata in Cargo.toml lists two authors, lain-dono and Adam Gąsior (Adanos020), with the repository pointing at the anhosh/egui_dock location.

The problem it solves is a gap in egui itself. egui gives you panels, windows and layouts for a single window, but an application that resembles an IDE, a level editor or a monitoring console needs something more. Users of such tools expect to drag a panel to another side of the window, resize it, close it, and get it back later.

The feature list is short and concrete. Opening and closing tabs. Moving tabs between nodes and resizing. Dragging tabs out into new egui windows. A highly customizable look and feel. A high degree of control over the behaviour of the whole dock area and of individual tabs. And manipulating tabs and the dock layout from code.

That last one is the item that separates a docking system from a static layout, and it is the reason to care about the crate's categories, which are gui and game-development. A dock that your own code can rearrange is a dock you can drive from a command palette, a layout preset system, or a project file.

The crate is MIT licensed, published on crates.io, documented on docs.rs, and the README carries a badge showing the egui version it targets, 0.36.

Nodes, tabs and the tree that holds them

The vocabulary of the library is worth learning from the source, because the feature list uses it without defining it. Tabs are the leaf panels you work in. Nodes are the containers, and a node is what you resize. The overall arrangement is a tree, which is the word that shows up in the optional serde feature and in the save and load example.

So the data model behind the GUI is a tree of nodes, each holding tabs, and the operations in the feature list are operations on that tree. Moving a tab between nodes rewrites the tree. Resizing changes the split of a node. Dragging a tab out into a new egui window lifts a tab out of the tree into a separate window, and the behaviour of that window is still yours to configure through the per-tab controls.

Two design choices deserve a comment. First, the library is not opinionated about the panels it holds: a tab is a closure or a view you supply, so the dock can host any egui content. Second, the level of control is deliberately high. The README promises control over the behaviour of the whole dock area and of individual tabs, which in practice means you can veto or react to a drag, adjust the styling, and drive the tree from your own code rather than only from mouse gestures.

The style of customization is also stated plainly as a feature, which matters for a docking system because the docked area has to sit inside an application that already has a visual identity.

Two dependencies, then set up egui first

The quick start in the README is two steps, and the first one is a dependency block:

[dependencies]
egui = "0.36"
egui_dock = "0.21"

Note that the two versions are pinned in step with each other. The egui badge in the README also shows 0.36, and the crate's own dependency on egui is declared with default-features = false, so the features you enable on your side are the ones that matter for the app as a whole.

The second step is the one people skip. The README says to proceed by setting up egui following its quick start guide, and only once that is done can you start using egui_dock, with more detail in the crate documentation on docs.rs. In other words, this crate assumes a working egui application already exists, and it is a layout component rather than a starting point.

The crate metadata adds a few practical details. The package version is 0.21.1, the edition is 2024 and rust-version is 1.95, so a recent toolchain is required. The include list packages only the Rust sources under src, plus Cargo.toml and LICENSE, which keeps the published crate small, and the keywords list tile, dock and layout alongside egui and gui, which is a reasonable summary of where it sits in the ecosystem.

The examples folder is where the effects are demonstrated

The repository carries example applications, and the README is specific about how to run them from the crate's root directory:

cargo run --example hello

The examples folder holds hello.rs, simple.rs, hidden_tabs.rs, reject_windows.rs, tab_add.rs, tab_add_popup.rs, text_editor.rs and save_load_dock_state.rs, and the folder also has its own README.md.

The names are a decent map of the behaviours you are most likely to need. hidden_tabs covers tabs that are not shown. reject_windows covers refusing to open a tab in a separate window, which pairs with the drag-out feature and with the per-tab control the README promises. tab_add and tab_add_popup cover adding tabs from code, which is the code-driven half of the feature list. text_editor suggests hosting an existing editor inside a tab, which is the common real use of a dock, and simple.rs is the baseline.

The save_load_dock_state example is special, because it is declared as its own Cargo entry with a required feature:

[[example]]
name = "save_load_dock_state"
required-features = ["serde"]

That means the example only builds when the optional serde feature is enabled, which is the right arrangement, since a layout that cannot be serialised cannot be saved.

The serde feature is what makes a layout persist

The optional feature set is small on purpose, and the whole of it is about serialisation:

[features]
default = []

# Enable serialization of `Tree`.
serde = ["dep:serde", "egui/serde"]

The comment says it plainly, the feature enables serialization of Tree. That is the object that holds the whole arrangement, so with the feature on, the layout becomes a value you can write to a file and read back.

Note the second half of the feature definition, which pulls in egui/serde as well as the serde dependency. Both sides need to agree on how their own data is represented, so the feature enables serialisation in egui too rather than only in the dock. The dependency on serde itself is optional and declared with the derive feature, and serde_json appears as a dev-dependency, which is what the save and load example uses to write the file.

Because the feature is off by default, a project that never persists a layout pays nothing for it. Because the example declares required-features, the build system refuses to compile that example without the feature, so the two stay in step.

The other side of the coin is that a saved layout is a snapshot of a structure that can change between versions. The CHANGELOG.md at the root of the repository is the place to look before you load a layout written by an older version of the crate.

egui_tiles, and the one layout difference that matters

The README has an Alternatives section, and it names egui_tiles from rerun-io, describing it as a library aiming to achieve similar goals in addition to being more flexible and customizable.

The specific difference is worth extracting, because it is the criterion that should decide between the two. One feature egui_tiles supports that egui_dock does not have at the moment is the ability to divide nodes into more than two children, which enables horizontal, vertical and grid layouts.

So the difference in approach is about the node model. A node in egui_dock splits in two, left and right or top and bottom, which is the classic docking arrangement and matches what every docking system has looked like since the 1990s. A node in egui_tiles can hold more than two children, so you can lay out a region as a grid rather than as a series of nested binary splits.

The README also states the counterweight, and it is not a small one. egui_tiles is much earlier in development than egui_dock and does not yet support a lot of features. The trade is therefore real features and maturity against layout flexibility.

For a tool that is essentially a window manager, either can be right. If your application wants a grid of panels in one region, egui_tiles is the answer. If you want tabs, drag-out windows and code-driven manipulation with a mature feature set, the README points you at egui_dock.

Community rules, an AI policy, and no tagged releases

The repository carries an unusual amount of process documentation, and the README asks you to read it before contributing: the contribution guide CONTRIBUTING.md and the AI usage policy AI_POLICY.md. The root also holds AGENTS.md and CLAUDE.md, and the README says this library is a collaborative project developed with direct involvement of its users, inviting issues, pull requests and discussions.

Where those discussions happen is also specified, and it is not the repository. A lot of the conversations take place on the egui official Discord server, in the #egui_dock channel. That is a sensible choice for a crate in someone else's ecosystem, since the questions that come up are usually about egui itself, and the answer is usually from the egui side.

The maintenance picture is straightforward. The last push to the repository was on 2026-09-23, there are no GitHub releases, and the crate version is 0.21.1 with a CHANGELOG.md tracking changes. So the crate moves on the 0.21 line while egui moves on the 0.36 line, and the two are expected to be kept in step.

For a library that sits this close to its host framework, that coupling is the main upgrade consideration. The version numbers in the dependency block are the contract, and a project that wants reproducible builds should pin them rather than float on the minor version.

Editorial conclusion

egui_dock suits Rust developers building editor-like tools in egui, where a single window with panels is not enough and users expect to rearrange, resize and reopen their panels themselves. It does not suit an application that needs grid style layouts with more than two children per node, since the README names that as a capability egui_tiles has and egui_dock does not, and it does not suit a team that wants a stable, released dependency chain, because the repository publishes no GitHub releases and the crate is versioned against a moving egui release. Check three things before you adopt it: that your egui version matches the 0.36 this crate targets, that you actually need the tree and tab model rather than a simpler split or tab widget, and that you are comfortable with a library that changes shape between minor versions. The last push to the repository was on 2026-09-23 and the crate version is 0.21.1.

Frequently asked questions

Official sources

1. anhosh/egui_dock on GitHub
2. Issues
3. License: MIT
4. README