Skip to main content

max / makeover-immediate

Say that the missing egui renderer is a quasi crate, not this one The note added in 0.17.1 read as though this crate declines to answer Chrome and Outcome::Over. It cannot: it depends on makeover-layout and not on quasi-router, so it draws described nodes and has never seen a Screen. It is the peer of makeover-webview and makeover-tui, one layer below the renderers that consume one. What is missing is the egui crate at that layer, which does not exist at all. GoingsOn quasicoherent a7f0c6c0.
Co-Authored-By
Claude Opus 5 (1M context) <noreply@anthropic.com>
Author: Max Johnson <me@maxj.phd> · 2026-08-13 16:32 UTC
Signed with PGP, not checked
Commit: 9ef0f62af44bb48e117ca3b2ac4109b5e8c417dc
Parent: 019b4d0
2 files changed, +13 insertions, -10 deletions
M Cargo.toml +1 -1
@@ -1,6 +1,6 @@
1 1 [package]
2 2 name = "makeover-immediate"
3 - version = "0.17.1"
3 + version = "0.17.2"
4 4 edition = "2024"
5 5 description = "The immediate-mode renderer for makeover-layout. Immediate mode is the constraint that matters, not the library: no cascade, no retained tree, one stroke per widget. Backed by egui."
6 6 license = "MIT"
M src/lib.rs +12 -9
@@ -127,15 +127,18 @@
127 127 //! are defined once in `makeover_layout`'s crate header, "Reach, focus and
128 128 //! the focus ring". [`makeover_layout::State::Disabled`] *is* drawn, because
129 129 //! egui has no opinion about it until told.
130 - //! - **App-level chrome is not drawn here yet, and that is an omission rather
131 - //! than a decision.** `quasi-router` names the affordances that outlive one
132 - //! screen — a `Chrome` of key bindings, and an `Outcome::Over` for a screen
133 - //! drawn over another — and the webview and terminal renderers both answer
134 - //! them. This one does not: an egui host wanting a command palette still
135 - //! writes its own. Written down because the silent version of this reads as
136 - //! "egui does not need one", and it does; nothing has asked for it yet. The
137 - //! shape it would take is not in doubt — egui has `Area` and `Order`, which
138 - //! is what an overlay is — so this is work, not a design question.
130 + //! - **App-level chrome is not drawn here, and it is not this crate's to
131 + //! draw.** `quasi-router` names the affordances that outlive one screen: a
132 + //! `Chrome` of key bindings, and an `Outcome::Over` for a screen drawn over
133 + //! another. Both are answered by `quasi-webview` and `quasi-tui`, and neither
134 + //! is answerable here, because this crate depends on `makeover-layout` and
135 + //! not on `quasi-router` — it is the peer of `makeover-webview` and
136 + //! `makeover-tui`, one layer below the renderers that consume a `Screen`.
137 + //! What is missing is the egui crate at *that* layer, which does not exist:
138 + //! nothing renders a quasi `Screen` in egui at all, and chrome is one item on
139 + //! the list such a crate would owe. Said here because this is where a reader
140 + //! looks for it, and because the silent version reads as "egui does not need
141 + //! a palette" rather than "nobody has built the renderer yet".
139 142
140 143 #![forbid(unsafe_code)]
141 144