ImGui is mainly used for debug rendering, but if you browse the screenshot threads, there quite a few 'end user applications' among them:

https://github.com/ocornut/imgui/issues/5886

No, it's supposed to be used for this purpose.

> Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user). It favors simplicity and productivity toward this goal and lacks certain features commonly found in more high-level libraries.

It's literally not designed for end user consumption.

ImGui is amazing to work with though. Like holy fuck is it pleasant compared to basically every other UI-development paradigm ever in the history of user interfaces.

Accessiblity, designer,... and it isn't even the first, that is how GUIs used to be developed in 16 bit home computers for games.

It is like static linking, it was also there decades ago.

There are reasons why the world has moved on from those approaches.

What's your point? Static linking makes a ton more sense than dynamic linking, except in a few special case niches (like plugin systems).

And OTH, event-driven UIs have also been around as long as UIs exist, that makes them at least as 'outdated' as immediate mode UIs.

The industry has moved beyond past decisions for a reason, that is the point.

Some of them keep being rediscovered in endless loops of fashion.

> Some of them keep being rediscovered in endless loops of fashion.

The reason for this is often that the environment (mainly the hardware) has changed so much that it may make sense to look into discarded old ideas again. For instance, dynamic linking was extremely important in the age of slow floppy discs and when RAM was counted in kilobytes, but those environmental factors are no longer an issue, and the advantages of static linking outweigh the disadvantages of dynamic linking again.

> The industry has moved beyond past decisions for a reason, that is the point.

And those “reasons” often SUCK; that is the point.

Yes but that's because it's an immediate mode renderer.

It feels intuitive and that's why it's the de facto standard for building debug tooling. But this intuitiveness comes at a price! No matter how hard you try, this will always be slower and computationally heavy compared to retained mode.

Great for some stuff, terrible choice for some other.

Your mixing up terms.

immediate mode rendering and immediate mode gui are unrelated. immediate mode gui libraries generally dont use immediate mode rendering because its realy slow.

immediate mode gui tends to be faster in practice because you just naturally end up with less code. also its very easy to write a retained mode ui ontop of an immediate mode gui library.

The term "immediate mode UI" is about the API philosophy, not about how it works under the hood, and especially not how rendering is implemented (e.g. Dear ImGui records a command list for the whole frame which is then passed to the API user for rendering, this is pretty much the opposite of an 'immediate mode renderer').

You are correct. I've also encountered it sometimes in internal business gui wrappers.

I wonder if this is because the default theme for it is somewhat ugly, and most developers aren't designers to make it look better. It is perfectly capable of rendering standalone applications, if you want it to...