I agree with you so much. There's many advantages to declarative and reactive GUI frameworks, but, god, they have so much "magic" going on at all times. Its hard to understand how the declarations get converted to pixels on the screen unless you spend a month digging through blog posts and source code to try and follow the trail of breadcrumbs.
'Rich' text editing might hit limitations with Dear ImGui's text rendering (e.g. not sure if things like italics, bold or strikethrough are supported out of the box).
Ok, rich text is always a good litmus test for a gui library. I get from this that ImGui is unfortunately not based on a good, versatile graphics engine.
Dear ImGui doesn't have a "graphics engine", the actual rendering is done by user-provided code which maps vertex- and index-arrays, and draw commands to system 3D APIs like D3D, Vulkan, Metal, GL etc...
Font handling is based on stb_truetype.h, but can be replaced with FreeType:
In any case, versatile text rendering is certainly not the design focus of Dear ImGui (AFAIK there's also no support for RTL layout), instead it is mainly targeted at quickly creating specialized UI tools (especially inhouse tooling for game development), less at creating end-user applications.
There's plenty of UI frameworks to create "end-user applications", but hardly any that fill the specific niche served by Dear ImGui.
There is microui if you want another one. Much more barebones as the name implies, but very easy to extend! Pleasant even if a bit quirky. Also nuklear, but haven't really gone much in depth with it.
Could you expand a bit on 'immediate mode design purity'? I've done immediate mode stuff from scratch and my experience had been "just write whatever code you need to get it to work," there hasn't really been an overall architecture guiding it. Never worked with an im library before.
Looking at the Nuklear example code again it turns out that I was remembering wrong. I seemed to remember that Nuklear requires to store persistent state on the API user side and pass that into the Nuklear functions, but this was actually microui 1.x (which also has been fixed in the meantime in microui 2.x).
Sorry about the confusion.
E.g. in microui 1.x defining a window worked like this:
The focus for this library is something else entirely which doesn't seem to align with your needs. Nevertheless, you are supposed to make the engine yourself, imgui is made to be bolted on top of that. And does a great a job.
I’ve been having to look at some react code lately. My god how I wish I were writing DearImGui code instead.