In Dear ImGui for instance, you can get the size of view containers and go as far as placing your UI elements at absolute positions (and also use a lower-level ImDrawList for custom rendering - which is also how you can extend Dear ImGui with your own custom-rendered UI elements, and all that absolute positioning and custom drawing is compatible with the automatic layout system).
The common misconception is that immediate mode UIs don't persist state between frames, but they absolutely do (it's just hidden from the API user). The 'immediate mode idea' is only about the public API, not the internal implementation (e.g. internally there could even be a traditional retained mode widget tree that's only modified, but not rebuilt each frame).
Err.. but I'm not talking about placing entities at absolute positions. egui supports that - that's how we get one widget in the center of the screen :)
I'm talking about having two labels in the center of the screen, making them full width, making the text word wrap, and having each label flow properly when resizing the window. That requires calculating word wrap for each label plus knowing where labels visually higher on the y-axis have decided to place themselves after considering word wrapping. Labels beneath other labels should get pushed downward when word wrapping occurs.
That seems really hard to achieve in immediate mode libraries without effectively recreating retained mode functionality yourself.
A layout engine is required in both cases. It's not necessarily more difficult in immediate mode than retained mode.
TFA demonstrates this exact functionality without "recreating retained mode". Check out the "Layout" section and note that the button is shrunk to the label, all of which is centered. The layout engine becomes an emergent property of the widgets rather than an algorithm evaluating a tree. Here, the code is the tree.
> That seems really hard to achieve in immediate mode libraries without effectively recreating retained mode functionality yourself.
The purpose of an IMGUI is to handle whatever data retention will simplify user's life. If you want to extend the IMGUI in some case it's perfectly adequate to do some that work yourself. Ideally the IMGUI infrastructure would make it as painless as possible.
