And when you need to read the source to figure something out, it's just a few files of pretty self-evident C-ish code.

Cornut recently did a 10 year retrospective of Dear ImGui: https://github.com/ocornut/imgui/issues/7892 - an interesting read for me, as a Dear ImGui library user for many years now, but worth your time I think even if you aren't a user yourself. There is a specific section about the scope of the library: https://github.com/ocornut/imgui/issues/7892#issuecomment-22...

because of the immediate mode paradigm it's not really a general purpose framework because the constant redrawing is just a complete resource hog in non real-time applications. The reason other graphics frameworks retain internal state (which Imgui exactly avoids) is to only redraw components when necessary.

It's so popular in games and real time visualization because that's one of the domains where you redraw constantly anyway.

> IMGUI does not mean that the library doesn't retain data.

> IMGUI does not mean it needs a continuous loop nor need to refresh continuously.

Second, Electron is not just UI. It's networking, file access, 2d drawing API, vector graphics, video conferencing, video playback, audio playback, video capture, audio capture, USB access, image decompressing, WebGL, WebGPU, WebAssembly, and many other things in a cross platform package.

It's trivial to make an app on one OS and ship on the other OSes without actually owning those OSes or even if you do own those OSes it requires almost zero knowledge of those OSes quirks and tools to make an app. Compare that to most other native cross platform frameworks and that's rarely true. Learning XCode on Mac, GCC/make/autotools on Linux, Visual Studio on windows, etc...

How would IMGUI perform the drawing, given the scrollbar is at (say) 20%?

This criterion means you'd have to roll your own solution. Otherwise, ImGuiListClipper exists for exactly this kind of thing.

https://github.com/ocornut/imgui/blob/864a2bf6b824f9c1329d84...

Yes. Good luck clearing that up. The programming community as a whole couldn't even get Object Oriented Programming right. It originally meant little machines passing messages to each other (Smalltalk, Objective-C). What we got was inheritance, encapsulation, and polymorphism (Java).

"Smalltalk encourages well-factored designs through inheritance. Every class inherits behavior from its superclass … all forms of ordered collections in the system will instantly acquire this new capability through inheritance."

"Modularity: No component in a complex system should depend on the internal details of any other component."

"Polymorphism: A program should specify only the behavior of objects, not their representation."

1981 "Design Principles Behind Smalltalk" Daniel H. H. Ingalls

https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

https://news.ycombinator.com/item?id=41261426

> The acronym is misleading because "immediate-mode" was initially coined as a reference to obsolete graphics API which made it very easy to render contents.

Is that actually true? From what I remember of hearing Casey (the person who coined the term) talk about it on Handmade Hero and various other streams, it's differentiating between 'immediate mode' and 'retained mode' GUI APIs (QT, GTK, Swing, MFC .. etc) which make you retain handles to UI elements. AFAIK it didn't have anything to do with the graphics API whatsoever ..? Right?

EDIT: Watched the video linked of Casey from 05, which I'd never seen before and was quite interesting. I'm not totally convinced that the small portion he talked about renderer APIs near the 10 minute mark substantiates the claim, but it might.

Direct3D had a retained mode up until version 3.0, but the only examples of it ever being used in a commercially successful game was LEGO Island and LEGO Rock Raiders.

Instead of supplying all the draw commands every frame, you would give it your 3D scene and it would draw it.

It was also very clear that D3DRM was designed by a different team than D3DIM.

I think you could also draw some analogies between server side and client side rendering. Where the authoritative view state lives is the most important bit I think.

> void UpdateUI()

Minimize state synchronization by effectively synchronizing state on each screen refresh?

> "Minimize state storage on user side."

> Immediate mode is a style of API where important state is kept in user code

Then reduce state stored in user code by storing "important state" in user code?

> "Minimize setup and maintenance."

I don't find the example convincing. It seems like any more complexity beyond this toy example puts you right back where you started. Building components by hand is stone age ideology regardless of how you push state.

https://github.com/ocornut/imgui/blob/master/examples/exampl...

> "Easy to use to create dynamic UI which are the reflection of a dynamic data set."

Which is great for a video game.

> The fact that we are even trying to put an official definition to a label is hindering people's imagination about the many possible areas of researches to be done in UI space.

Well said, but then the author proceeds and lists what IMGUI is and what it’s not.

My opinion is that we may just think about IMGUI as “the stuff that dear-imgui does”, which people understand well. And yes there’s a loop, and things get redrawn all the time and so on.

Everything else that borrows concepts from that is IMGUI-ish. I for myself definitely use some IMGUI concept when I do js apps, but is it imgui? Definitely not. Is it imgui-ish, hell yeah.

Trying to make the term IMGUI mean “good way of doing UI” is not gonna work…

Can the app stop generating wakeup interrupts and let CPU/GPU sleep?

Yes -> this means app events (like network transfer) need to be able to generate "update" events, which means those events need to be directed somewhere, which means retained mode.

No -> this means GUI is allowed to poll non-stop and thus can check every variable 60 times per second to support immediate mode.

Dear ImGui's sample code currently does draw every frame even when nothing is happening. Omar has said that he would eventually like to change this and it's on his roadmap, but it's low priority because he is currently targeting game industry users and doesn't want to attract a lot more users in other areas that will add to his support load and dilute his focus. [1]

He also has said the same thing about accessibility and fancy theming. These features are good examples of why "the stuff that dear-imgui does" is not a good definition of immediate mode. People often assume that anything Dear Imgui doesn't do is hard or impossible for any immediate mode API, but that's far from the truth.

Omar is only one guy. He has a target audience in mind and is not trying to satisfy all use cases at once. You have to remember that when comparing Dear ImGui to a framework like Qt or SwiftUI or whatever that has hundreds if not thousands of developers contributing to it.

[1] https://github.com/ocornut/imgui/issues/7892

Unfortunately, all people seem to have gotten out of that was if(doButton(...)).

The author of microui described an interesting approach to this here https://rxi.github.io/cached_software_rendering.html

[1] https://guide.elm-lang.org/architecture/ [2] https://en.wikipedia.org/wiki/UML_state_machine

For example, ImColorTextEdit renders an ImGui:Dummy() to create a dummy widget of a specified width and height which defines the scroll area, and then based on the current ImGui::GetScrollX() and ImGui::GetScrollY() it uses ImGui::GetWindowDrawList()->Add{Rectangle,Line,Text, etc} to custom render the contents inside the widget based on what should be visible at the scroll positions. Since it's custom code it would be easy to use a zoom param to adjust the scale of things and what is submitted to the draw list.