Dear ImGui rebuilds its interface every frame from calls, which is the same instinct as here. Two things differ: keal-view describes a tree and then lays it out, rather than emitting geometry as it goes; and it does not run at the frame rate of a game — it sleeps until something happens.
| Dear ImGui | keal-view |
|---|---|
ImGui::Text("Hi") | label("Hi") |
if (ImGui::Button("Go")) { … } | button("Go", { -> … }) |
ImGui::SliderFloat(&v, …) | slider(v, { x -> … }) |
ImGui::SameLine() | row([…]) |
ImGui::PushStyleColor | the theme, read by everything |
ImDrawList | custom({ p -> p.canvas… }) |
DockBuilder | Dock, leaf and split |
In immediate mode a button reports last frame's click as this frame's return value. Here the tree is built, laid out, and then handed the events, so a handler runs against the layout the user actually clicked on — including on the frame where the window was resized.
Dear ImGui produces vertex buffers for a renderer you supply. keal-view fills a buffer of 0xAARRGGBB pixels on the processor and hands it to the window. Anti-aliasing is analytic rather than multisampled, so a curve costs what its edge costs and there is no quality dial.
ImGui keeps its own internal state keyed by an ID stack you have to reason about. Here the same problem is solved the same way — identity — but the identity is a node's position in the tree, and .keyed("…") is how you say when position is the wrong answer.