Dear ImGui: Graphical User Interface library for C++ | Hacker News Reader

Dear ImGui: Graphical User Interface library for C++

github.com

146 points_benj109 comments

Dear ImGUI is amazing and I wish all UI development was so easy and simple.

That said, be aware its original purpose is as a UI for internal game dev tools and not customer facing tool. It's neither international friendly nor accessibility friendly. Those are 2 feature usually not needed for internal tools.

It’s amazing on its own but not so much when combined with other libs.

Even Rockstar devs use it, saw it on some of the leak videos of gta6

I've written video game editors in Win32, MFC, wxWidgets, Fox Toolkit, Qt, Cocoa and Dear ImGUI.

I will never use anything other than Dear ImGUI from now on. The explicitness, lack of state, speed of development and maintainability of the code means it wins hands down.

Well worth investing your time in and if you are a leader in the games industry well worth supporting financially.

I believe you mean the (general) transparency of state? But yes, that's quite great when you're getting stuff together quickly. It's even used for more serious stuff, where immediate mode is a necessity.

The "lack of state" refers to being immediate mode rather than retained mode.

It does require some state in the back for everything to work as it does.

Of course. The API is stateless but the implementation isn't. That's usually how good immediate mode APIs work.

Dear ImGUI is just retained mode under the hood, with the name of the widget acting as the index. The API presents immediate mode, but it isn't really. If a "good" immediate mode API just hides all the state under the hood, then I think one should call it something other than immediate mode.

The thing is, immediate mode UIs are not really usable, because a widget needs internal state, so a pure immediate mode UI would require the caller to carry around all that state. Obviously that is burdensome, which is why Dear ImGUI hides it for you. But in my opinion, it's a bit of a fraud to call that an immediate mode UI, when it retains a copy of state behind its back.

Since words have to mean stuff, I would definitely call it immediate mode, it's not trivial at all to hack a generic retained mode UI library into being as flexible to what's on screen as ImGui. A generic retained mode design would more rather require pointers to some dependency state to check per update, with ImGui the schema gets rebuilt constantly, instead of being reactive. And there is definitely use cases for this design, constantly changing stuff would probably fit with Dear ImGui or others better than with a generic retained mode UI toolkit.

The person who coined the IMGUI term (Casey Muratori) literally defined "immediate mode gui" as a concept relating to the API/facade, regardless of what the UI system internally owns or store or manage.

So basically you are dismissing an existing definition to turn it into your own to say that existing libs are not fulfilling that definition.

why not use game engine(godot,etc) directly and write your editor on top of that instead?

ImGUI is cool for gaming yes, but not good for daily normal GUI desktop apps, per the design.

Not everyone uses an off-the-shelf game engine. Plenty of games are written with a bespoke engine.

It is nice for a developer, but I don't like it as a user. It doesn't look or feel good or right, nothing works like you're used to, keyboard support is clunky. I like it as cool a dev tool but I don't want to do real work using that UI.

Can you suggest some improvements? Perhaps there are some low hanging fruits.

Spotting it in various videos of scientific, game development & graphics tools is a bit like hearing the Wilhelm scream in movies.

Yeah it's a heartwarming open source success story in game development. Everybody uses it for internal tools (just check their sponsors list to start with), and it occasionally shows up as like a debug menu in production code.

I've dabbled with Qt and other heavy GUI tools before. Switching to Imgui was a breath of fresh air.

And I love how it allows me develop for Windows, Linux and MacOs with minimal overhead.

Looking at the leaked GTA VI videos and seeing ImGui being used by Rockstar internally is pretty neat how even a multi-billion dollar studio will use the same open source project we all use.

Reminds me of that „A PROJECT SOME RANDOM PERSON IN NEBRASKA HAS BEEN THANKLESSLY MAINTAINING SINCE 2003 image.“

Sorry for caps (transcribed from image).

https://xkcd.com/2347/

Alternatively, the "runk" tool https://www.reddit.com/r/ProgrammerHumor/comments/umg9ps/run...

> Sorry for the caps

You can use tr to quickly convert it to lowercase:

    pbpaste | tr '[:upper:]' '[:lower:]'

(Though I usually paste text in VSCodium and convert it there.)

I just used Dear ImGui in a VSCode tab in the last couple of weeks [1] :)

...indirectly by embedding a home computer emulator with a Dear ImGui debugger UI, compiled to WASM+WebGL running in a webview panel, but the idea to use Dear ImGui for tooling UIs in VSCode extensions where HTML+CSS might be too awkward is certainly interesting (think not just "traditional UIs", but also things like noodle-graphs, flame-graphs, diagrams... the vector renderer coming with Dear ImGui is great for that type of stuff).

[1] https://marketplace.visualstudio.com/items?itemName=floooh.v...

> ..by embedding a home computer emulator with a Dear ImGui debugger UI, compiled to WASM+WebGL running in a webview panel...

People wonder why their Electron apps use 16GB of memory.

...and yet there's no realistic way to implement such an extension for any other IDE without resorting to per-platform-compiled and potentially unsafe native code :)

The embedded emulator including the Dear ImGui debugging UI compiled to WASM is just around 700 KBytes, runs on all platforms (even in the VSCode browser version) and is safely sandboxed, that same code compiled to a native executable on macOS is 847 KBytes, doesn't run on any other OS without compiling another version, and would be blocked to run anyway because it is potentially unsafe.

Turns out VScode is indeed a web browser in disguise, who would have thought!

Downvoters, educate yourself a little bit: https://en.wikipedia.org/wiki/Electron_(software_framework)

ImGui is brilliant. I can highly recommend this hex editor built using it: https://github.com/WerWolv/ImHex

Naive question from someone who hasn't touched GUI programming since visual studio/QT GUI designer circa 2005 :

Isn't a more declarative approached like XAML/QML (or even html/ccs) a better way to represent a GUI interface as opposed to an imperative list of command embedded inside the business logic of the application ?

How does IMGUI handle theming, reflow or even GPU acceleration on different platform ? It seems to me that a more declarive representation would allow for better tooling and easier split between presentation and themes to match the native platform.

Dear ImGui code actually looks quite declarative, except that the actions are directly 'inlined' into the UI declaration as code.

For instance:

    if (ImGui::Button("Click Me")) {
        // do the stuff that should happen when the button is clicked
    }

To hide a part of the UI you simply skip the code which describes that part of the UI.

    if (!btnHidden) {
        if (ImGui::Button("Click Me")) {
            ...
        }
    }

Your code describes what the UI should look like in the current frame, and what should happen on user interactions, but without event listeners or callback functions.

How you keep the UI declaration separate from the "business logic" is up to you. Dear ImGui allows very close coupling (which quite often is actually an advantage for adhoc UIs), or you can keep both separated as much as you prefer.

> How does IMGUI handle theming, reflow or even GPU acceleration on different platform ?

Dear ImGui actually builds an internal "stateful" representation of the UI declaration (it needs to remember at least some state between frames, otherwise simple features like moveable/sizeable windows wouldn't be possible) and then generates an optimized list of rendering commands that plug almost directly into 3D rendering APIs like D3D, Metal, GL etc... (the renderer is implemented outside of Dear ImGui by yourself, however Dear ImGui also comes with pluggable example renderers and window system glue for pretty much any platform and 3D API).

Themeing/skinning is indeed a weak point of Dear ImGui specifically, other immediate mode UI frameworks like Nuklear offer more flexibility there, but this has nothing to do with the imgui philosophy, only with feature sets of specific imgui libraries.

Are you asking about the IMGUI paradigm or DearIMGUI the library? In the case of DearIMGUI: - it does not handle theming (but forks do) - I don't know what reflow is - in a way, GPU acceleration is the default. In fact, DearIMGUI doesn't handle anything at all in that regards because it doesn't have to. You are the one responsible for drawing, DearIMGUI just outputs you a vertex buffer that you send to the GPU the way you want to. There are proposed backends but you can totally roll your own. People even have made networked and web backends. I don't know how those work.

ImGui is engine/GPU agnostic

Themeing isn't a just a retained mode thing, you can do wonders with immediate UIs, even though (dear)ImGui doesn't provide much, you can still do wonders: https://github.com/ocornut/imgui/issues/707#issuecomment-362...

The gaming cheating community is quite creative as well: https://www.unknowncheats.me/forum/c-and-c-/505940-advanced-...

More on that topic: https://www.youtube.com/watch?v=Z1qyvQsjK5Y

I’ve worked with a lot of different UI frameworks (both native and web) and ImGui is definitely my favourite

It’s just so simple

For example adding an input box for editing a float value is one line of code and the syncing is done by just passing it a pointer.

I'd like to see a middle ground between immediate mode and retained mode, where the UI is more like a scene-graph where you have nodes with transforms, but you can draw anything inside them, and the framework will keep track of all the matrix math for you like a game engine would. Maybe no one would find that useful, but its something I'd like to tinker with.

My personal IMGUI library [1] is what I call "partially retained" in that there is an immediate mode API similar to dear imgui or nuklear on top, but under the hood the immediate mode API just manages retained mode object graphs for you automatically.

This is a fantastic (imo) way to build user interfaces, because sometimes the most convenient way to manage state or construct a complex widget is to write a retained mode object that hosts some other child objects, and in other circumstances it's most convenient to write a modal dialog or something by just slamming out some imgui code in a standalone function.

I also think the imgui approach to layout (use an algorithm that can fully reconstruct your layout from scratch every frame without much of a performance penalty) removes a lot of potential bugs and quirks that are common in UI, like one-frame glitches or having to manually propagate state through a bunch of objects and layers. Though imgui approaches have their own downsides, like the "page tearing" issue. I've had to do some weird contortions to solve that one in my own code and I still get bugs occasionally.

The game I'm building right now does almost all of its scene layout and UI as a single graph of components that mix retained and immediate mode, and it's been a relaxing way to do things compared to the 'manually paint widgets in places and do hit testing' approach I've used for some previous titles.

A large portion of the UI is constructed via what I'd call 'value replication', where a container control is attached to a list of game objects (entities, components attached to entities, parameters to a script) and then the container automatically creates a list of child controls for each game object automatically. This allows easy virtualization (i.e. only having 20 controls to represent a scrolling view with 1000 items) and means I don't have to manually do a bunch of state synchronization.

1: https://github.com/sq/Libraries/tree/master/Squared/PRGUI

Super cool, thank you for sharing!!

This sounds very much like QGraphicsScene (https://doc.qt.io/qt-6/qgraphicsscene.html#details)

Sounds similar to CoreAnimation or DirectComposition.

My introduction to this UI was actually from a (unapproved) 3rd party modding framework developed for the MMORPG Final Fantasy 14.

The tool creators needed some way to provide mod developers with access to a unified UI, and hooking the game’s built-in UI was far too high effort for the reward.

I played around with it to develop a couple mods for fun and have since become a huge fan of it, and started using Dear ImGUI to add interfaces to some of my personal tools that were previously CLI-only.

I've used Dear PyGui [1], which is based on this, and it has been a mixed bag. It's fast and basic functionality is super simple. The documentation is somewhat lacking when you wanted to start doing something non-standard. I would still rate it quite highly all things considered.

[1] https://github.com/hoffstadt/DearPyGui

I worked at multiple major video games studio and they all used ImGui internally, most of the time it was for debug in-game ui.

Beautiful interface design there, and it's fully customizable to your liking as well. It also supports keyboard shortcuts.

You really think so? This is really my biggest issue with Dear ImGui, I think it just looks awful. The design is just not great, and stuff like text rendering has been terrible in every Dear ImGui UI I've seen. Especially on macOS, the native applications there really make ImGui stuff look pretty crappy. Electron apps also generally speaking just look way better, IMHO (Electron has other issues obviously, but the ones I use regularly look pretty good). Like, imagine VSCode or something with the graphical style of the screenshots on the GitHub page.

Maybe you can customize it and make it look great, but the "out of the box" experience is just... oof.

Yes, you can customize it, both the color scheme and the element spacing. And the font scaling (the internal resolution in the texture) can be fixed to make the fonts look nicer. Someone made a subpixel font rendering patch for ImGUI as well.

ImGui supports multiple text rasterizers.

Normally, in a game there is a completely separate not-awful-looking GUI system for the player, pushing Dear ImGui towards the opposite niches: simple in order to be easy and efficient to write rather than complex in order to be general and flexible, evolution through changing (mostly adding) widgets and assimilating more data rather than through improved appearance and behaviour of a relatively simple and stable GUI, "just working" and low churn rather than configurable, cheap rather than accessible, and so on.

In school, another student and I used ImGui for a music sampler. In retrospect it could have a more friendly interface heh.

https://github.com/EmissionControl2/EmissionControl2

Arguably music/"creativity" apps is exactly where immediate mode GUIs shine the most. Predictable latency, instant feedback, ease of mapping the state to a visual representation, reliability and robustness. I can't think of a better match.

Does anyone know what the name is a reference to?

Idk about “dear” but ImGUI I believe stand for “immediate mode graphical user interface”

From the faq https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-w...

Q. What is this library called?

This library is called Dear ImGui. Please refer to it as Dear ImGui (not ImGui, not IMGUI).

(The library misleadingly started its life in 2014 as "ImGui" due to the fact that I didn't give it a proper name when I released 1.0, and had no particular expectation that it would take off. However, the term IMGUI (immediate-mode graphical user interface) was coined before and is being used in variety of other situations e.g. Unity uses it own implementation of the IMGUI paradigm. To reduce the ambiguity without affecting existing code bases, I have decided in December 2015 a fully qualified name "Dear ImGui" for this library.

My first guess would be it is supposed to sound like "Dear Imogen". However, it wasn't initially conceived of as a reference to anything. The "Dear" was tacked on to qualify the name [1].

[1] https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-w...

Just seems like a weird way to qualify the name is all.

I think it fits, Dear ImGui is the most popular immediate mode GUI, and it's what most people think of when they hear "imgui" even though I've seen people shorten "immediate mode GUI" to "imgui" too.

Help me out here. How does it being "the most popular immediate mode GUI, and it's what most people think of" translate into "Dear ImGui"? A couple explanations have been offered in response to the question, but they're all non-answers. As if the explanation is self-evident and need not be explicitly stated. And as if the respondents aren't able to grok that an explanation is exactly what the question is asking for.

Is there a non-webgpu wasm/emscripten demo somewhere? I remember seeing a ton of them earlier. Or maybe I'm thinking of the rust version:

https://github.com/emilk/egui

There's a bunch here

https://github.com/floooh/sokol-samples

For example, the basic demo window:

https://floooh.github.io/sokol-html5/imgui-sapp.html

Also see the interactive web manual https://pthom.github.io/imgui_manual_online/manual/imgui_man...

An incredibly powerful GUI library. Not easy to use, only for experienced developers. It's quite useful for scientific visualization as well! Many kudos to the main developer and the community.

> Not easy to use, only for experienced developers.

Personally I found it a lot easier to grok than (for example) React or Qt (as two examples from opposite ends of the spectrum).

The related DearPyGUI is so cool. https://github.com/hoffstadt/DearPyGui

I have been a fairly devoted user of Gtk in my Python programs for about 20 years. Back then, it was a clean, simple, functional toolkit that just worked.

Dear ImGUI cleans Gtk's clock in the "clean", "simple", "functional", and "just works" categories these days, and I am currently porting my biggest side project from Gtk to Imgui.

If you are trying to "integrate with the (GNOME) desktop", I'm sure you should still use Gtk, but for most purposes I don't see the point. It seems from the outside like there are few core Gtk developers left, and they are basically in life support mode for an entire desktop suite, one that is stuck between two broken display engines (Xorg and Wayland) with no way to really fix things and every desktop Linux user expecting miracles.

ImGUI is just a busy dude banging away on a single toolkit, without the baggage of millions of nontechnical users to support. As a developer, I know which one is going to be producing the good stuff.

Is the selling point for this easier custom widgets than in other frameworks?

Maybe my standards are too low, but for quick internal tools, it's hard to beat 30-year-old Tcl+Tk.

The selling point is described quite well under "The Pitch" section of the README.

Unlike most other toolkits, this one doesn't actually handle its own rendering/contexts. It outputs the low-level vertex buffers and textures that you can pull into your own graphics pipeline. Which means you can integrate it into any sort of 3d application or backend that you want.

Related. Others?

Visual Node Graph with ImGui - https://news.ycombinator.com/item?id=37702059 - Sept 2023 (90 comments)

ImPlot: Interactive plotting library, ImGui style - https://news.ycombinator.com/item?id=37000594 - Aug 2023 (39 comments)

ImGUI Ported to a LiteX SoC - https://news.ycombinator.com/item?id=34540206 - Jan 2023 (12 comments)

Show HN: ImThemes – a Dear ImGui theme browser and editor - https://news.ycombinator.com/item?id=32290700 - July 2022 (1 comment)

Show HN: Python Live GUI – A Hybrid of Dear ImGUI and Phoenix LiveView - https://news.ycombinator.com/item?id=31679945 - June 2022 (19 comments)

Dear ImGui – Bloat-free graphical user interface library for C++ - https://news.ycombinator.com/item?id=24986908 - Nov 2020 (180 comments)

ImPlot: Advanced 2D Plotting for Dear ImGui - https://news.ycombinator.com/item?id=23128262 - May 2020 (6 comments)

Dear ImGui: Bloat-free Immediate Mode GUI for C++ with minimal dependencies - https://news.ycombinator.com/item?id=23065472 - May 2020 (1 comment)

Runtime Compiled C++ Dear ImGui and DirectX11 Tutorial - https://news.ycombinator.com/item?id=22233109 - Feb 2020 (12 comments)

Could ImGUI Be the Future of GUIs? - https://news.ycombinator.com/item?id=19745809 - April 2019 (124 comments)

Immediate Mode GUI - https://news.ycombinator.com/item?id=19744513 - April 2019 (128 comments)

ImGui: Bloat-Free Immediate Mode GUI for C++ with Minimal Dependencies - https://news.ycombinator.com/item?id=18121600 - Oct 2018 (1 comment)

ImGui: Bloat-Free Immediate Mode Graphical UI for C++ with Minimal Dependencies - https://news.ycombinator.com/item?id=16193560 - Jan 2018 (1 comment)

Using ImGui with modern C++ and STL for creating game dev tools – Part 2 - https://news.ycombinator.com/item?id=12148661 - July 2016 (33 comments)

Imgui: Immediate Mode Graphical User Interface with minimal dependencies - https://news.ycombinator.com/item?id=8161601 - Aug 2014 (41 comments)

Sol on Immediate Mode GUIs (IMGUI) - https://news.ycombinator.com/item?id=4201748 - July 2012 (15 comments)

A word of caution that Dear ImGui is specifically made for building internal tools quickly rather than production-grade UIs. Relevant quote from the docs:

> 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.

Here's a quote from my comment [1] on an earlier discussion about Dear ImGui vs. "bloated" browser APIs:

> This is what I hear when I enable VoiceOver on macOS and open Discord (either the web app or the desktop app):

> 1. “Discord, friends - Discord window, direct messages, selected cell”

> 2. “You are currently on a cell inside of a table. To navigate the cells within a table, press…”

> 3. (when navigating with the keyboard) “1 mention, $SERVER_NAME, cell” “$SERVER_NAME, cell” etc

> And here’s when I do the same with a random Dear ImGui app I have installed:

> 1. “$APP_NAME, $APP_NAME window, $APP_NAME window”

> 2. “You are currently in a window”

> 3. (when navigating with the keyboard) [silence; no additional instructions]

[1] https://news.ycombinator.com/item?id=37302809

Yet people do indeed make professional software with it, such as RemedyBG.

Is RemedyBG actually accessible to blind users though?

No. Just bought it so I could check. Edit: I'd be happy to spend some time helping the developer with this if they're interested.

Sure, if you put in a lot of effort you could probably make a professional app with it. You'd need to recreate a bunch of features that come for free in more "bloated" UI libraries. But you could do it! More likely, though, is that you won't and your "professional" app will just end up being bad for lack of those features.

This comment-and-response pair has a really weird "shape".

You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.

Consider the following hypothetical:

Person A: Here's little advice: don't take up smoking. Smoking is bad for you.

Person B: Yet people smoke—my cousin, for example.

The point of the other comment wasn't that it isn't happening or that it's physically impossible to even try. Indeed, the fact that it's being done—or that people are attracted, at least, to trying to do it—was rather the entire premise of their "word of caution".

I see a different "shape". To me it looks like the same accessibility song and dance that happens every time a GUI library is the topic.

Is accessibility not a worthwhile concern?

What answer are you expecting? This question is borderline flame bait.

It seemed like you were criticizing the "accessibility song and dance that happens every time a GUI library is the topic", as if you think accessibility concerns are over-blown. If that wasn't your intention, I suggest you clarify what you actually mean.

It seems this might not be the case for American English, but "song and dance" is only ever dismissive in British English. The implication is that the complaints are a needless distraction, due to the relative insignificance of the topic.

Yes, that’s the case for American English too.

Probably not for internal custom tools.

I agree, which ... is why jakelazaroff is warning that ImGui is meant for internal custom tools, not tools where things like accessibility is a concern.

Accessibility is only not a concern for internal custom tools if you're certain you're not going to hire anybody with a disability that requires those accessibility features. (You shouldn't be certain of this, because it means you're probably breaking the law.)

This is kind of a kinda ridiculous argument. You're not gonna hire a blind level designer or blind character artist.

I don't see any reason you couldn't hire a blind level designer, but sure, there may be some subset of "internal tools" that you can make that assumption for. But the topic wasn't "internal tools for visual artists", and a lot of workplaces have internal tools that are inappropriately and unjustifiably inaccessible.

Accessibility is one (important) consideration but it's true that tools with a small, known subset of users can afford to ignore some constraints. For example, if you're a small American company, your internal tools might not need to support right-to-left languages.

This is for the creators to decide. Nobody else has a say, really.

Accepting this, for the sake of argument: sounds like warnings such as jakelazaroff's are a good thing then, to make sure creators are informed enough to decide.

Except the law in Europe.

I wouldn't go that far. But "this lacks accessibility" isn't sufficient reason to rule something out, imo. It's better for a piece of software to exist, without accessibility accommodations, than it is for it to not exist at all.

No, there's a tradeoff. If non-accessible software outcompetes and crowds out accessible software, that degrades the ability of people who need accessible software to use their computers. It is entirely reasonable for people who think that people with disabilities should have equal access to technology to advocate against the development of software without accessibility features.

It's a bit sad that something like an iMessage client for Android gets so many people here passionate about the ethics of access to platforms, but you get downvoted pointing out that certain tools/strategies for building software can leave whole classes of people out of computing due to factors entirely out of their control.

And you get downvoted for pointing out that here in Europe you're required by law to make software accessible. (At least in theory, don't know if it's enforced at all.)

Well, here in Europe you can get sued if you provide a non-accessible software. (Games are excluded and a photo editor can of course assume that the user can see etc.)

If the topic is a tool that's missing an important feature, then of course people will discuss why that tradeoff has been made.

Ship or don't. If the calculus boils down to this, then making suboptimal choices isn't necessary wrong.

Why should internal tools not have these things? That kind of argument smells of, internal tools can be slow. No.

Seems we should lift up Dear ImGui -- contribute, donate, feedback (document, gather requirements, etc), etc -- as opposed to suggest we not use it.

I don't think they shouldn’t on principle, but they might not need to have them. For example, if there's a limited number of people who are going to work with the tools, and you know that none of them need such features, it could be entirely reasonable not to worry about them.

That's making a bet that you'll have absolutely no need to hire someone for that team nor that any of the existing members of the team will develop the need for accessibility features.

Dear ImGui is lacking good and focused code contributors, I'm stretching myself quite thin already and unfortunately pragmatically it currently wouldn't be wise for me to attempt working on accessibility features :( Right now the state of things is that a majority of even the simplest PR are poor quality, so I'm not too hopeful that such a complex feature would magically start getting good contributions. I am personally just accepting that things are going to take years to move forward. I'd rather have them more slow and stay sane. Dear ImGui is intentionally gated and made fugly for those reasons as well.

But any effort to document, specs, clarify etc would be helpful and not just to Dear ImGui.

Accessibility is a whole world that is hard to grasp when you are not a end-user, API are large, confusing, poorly documented, and I presume that there are a large variety of tools and use cases and it's even hard to gauge what are the low-hanging fruits that would be the best to implement/bind.

Given how obfuscated Web stacks are nowadays (since they do try to prevent unauthorized scrapping and automation), I'm honestly also a little bit surprised that nowadays screen readers aren't relying on OCR more?

I appreciate the work you do and I think what you're saying is completely fair and understandable.

Supporting screen readers - e.g. accessibility, apart from the obvious benefit to the users, gives you almost for free testing/automation abilities too

Good Testing/Automation is never free lunch AFAIK but Dear ImGui has a testing/automation system: https://github.com/ocornut/imgui_test_engine

Yes, I'm super excited about this ^^^, but I was speaking in more general manner - e.g. accessing any kind of UI for basic functionality without need to know the internals, or use their own testing system (like QTest, or what Omar posted above with DearImGui, or something that exposes a white/gray box).

Inevitable, you have to reach out to the specifics of the UI end, but for most of the tests all you may need is - Run App, Accept Some License / Button, Press something else, then something else - and it elevates some confidence that at least it can run and go that far (sometimes changes can break even this).

So such tests can be coded by completely autonomous team, not having to deal with how you've build the software to begin with, or coordinate changes you've made later (apart from how the UI works).

Tools that are popular with developers tend to evolve into tools that end up in use by everyone.

Your caution isn't wrong, but ultimately it may be futile.

Ultimately, I only really care about the outcomes. If people want to use Dear ImGui for their production apps and put in the work to make it, well, production-ready, I'm totally fine with that.

I've also played around with the Rust version egui, and with the eframe template it's super easy to bang out super quick GUI tools on github pages (for example, I made a basic guitar fretboard chord finder [1] to help me learn guitar in a few hours, plus a few more hours refining it)

The mental model of immediate mode guis makes it really easy to work on it as a side project with 10-20 minutes here or there before bed, though doing proper layout to make it look nice is sometimes a challenge. The other advantage is that I can just jump into the implementation, and the egui code itself is pretty easy to grok.

[1] https://kelvie.github.io/chord-finder

One thing I will add is that this paradigm really encourages either making a ton of functions (which IMO makes code flow harder to read for these kinds of low-effort projects), or having a lot of scoped statements.

A good addition would be something like how flutter's LSP-based tools, which I use in Emacs), have a "wrap with widget" auto-refactoring tool, for e.g. when you want to wrap an entire widget tree in a new layout without having to do it manually.

Egui is not the "Rust version" of ImGui. There's libraries which allow for ImGui in other languages by applying the hourglass pattern first (making a C api for the C++ api), to allow for the creation of bindings, since most languages support C FFI, and then somebody writes an API in the target language which calls to (and maybe extends) the C api.

egui is pure rust. It is not a rust binding of ImGUI

I am aware. I am asserting the distinction there.

Reply on news.ycombinator.com