Not that I know of, the issue is often that most of them run through graphics API bindings currently.
In many ways immediate mode UI's is a relative of declarative UI's like React and I think we might see hybrids or implementations of either on top of the other.
Why? Right now immediate mode UI's often lack accessibility,etc and since it's often game/graphics focused there has been little push to fix this afaik. But there really is little reason not to implement an im-gui that renders to a diff-able tree that then is translated to "Native UI components".
Imo one big reason why declarative UI's hasn't caught on is because C/C++ really don't have the best ergonomics for building "flexible" data structures or immutable updates, by turning it around to using im-gui style rendering it could probably be solved fairly smoothly.
> Imo one big reason why declarative UI's hasn't caught on is because C/C++ really don't have the best ergonomics for building "flexible" data structures or immutable updates, by turning it around to using im-gui style rendering it could probably be solved fairly smoothly.
I suspect it has more to do with the sheer amount of effort to build a new UI toolkit (text rendering itself is an insane amount of work) and so very few UI toolkits actually make it to a usable MVP whether they are traditional/widget-based or reactive.
I think the classic OSS community will be a bad starting point for this just for this reason, you either start by booting off GTK/QT and end up with a bloated monstrosity that many hardcore C++ developers from other domains will bypass or start from scratch and struggle with basics like text-rendering that you mention.
As someone coming from gamedev, I'd prefer something like this to be few files (maybe even single-file-header lib) that mostly wraps win32,osX,etc core API's for a native experience with good accessibility,etc support. My declarative-style experiment was maybe 6-7 files medium sized files (and I think the implementation ran away with C++ bloat and complexity trying to get the API to mesh updates with C++)
The term "immediate mode" is only about the API, not about how things are implemented under the hood, e.g. an immediate mode UI can map to traditional stateful UIs, it's just not done yet very often because of ImGui's roots in the gamedev world (where it is important to easily integrate with existing game rendering engines).
My comment was written from seeing that experiment but also implemented an experiment for a React style declarative API over Win32 earlier and realizing how bad developer ergonomics became together with realizing doing it how close it is to an imgui flow.
Still the fact is that this is the only one I know of and in general accessibility hasn't been a big concern so far (And the imgui name isn't an accident considering the history).
Anyhow considering how laborious "modern" API's like UWP is, how badly declarative API's continue to map to C++ and the frequency at which gamedev rooted developers are asking for how to do "native UI"'s in C++ the time is definitely ripe for a serious one to emerge, the question is though if there will be one with enough momentum to become truly useful or if we'll end up with a bunch of small hacks that kinda covers some bases but don't end up being a good option for the majority.
In many ways immediate mode UI's is a relative of declarative UI's like React and I think we might see hybrids or implementations of either on top of the other.
Why? Right now immediate mode UI's often lack accessibility,etc and since it's often game/graphics focused there has been little push to fix this afaik. But there really is little reason not to implement an im-gui that renders to a diff-able tree that then is translated to "Native UI components".
Imo one big reason why declarative UI's hasn't caught on is because C/C++ really don't have the best ergonomics for building "flexible" data structures or immutable updates, by turning it around to using im-gui style rendering it could probably be solved fairly smoothly.