[yudlejoza]

I just spent 20 minutes on imgui, as well as retained-mode and immediate-mode, and boy do people love to reinvent the wheel.

My guess: they're going to gloat over immediate-mode for a decade or two, then some folks are going to develop retained-mode code (library/framework/whatever) on top of imgui, and then they're going to gloat over that for another decade. And they'd reach a point where we are today. Fantastic.

The guy in the famous 40-minute video, the beginning of which explains RM vs IM, appears to make claims that he's too busy and doesn't have time writing research papers. Wow. He discovered IM on his own probably, and reached the conclusion that he's discovered something no one else has discovered and should be writing a research paper. Jeez.

[Gene_Parmesan]

Who in their right mind would implement retained mode on top of imgui? I'm really struggling to see the thought process that would lead someone to go down that path. It's not like there's a dearth of retained mode GUI frameworks.

Really, the reason people get excited about dear-imgui is the fantastic ease with which it allows you to create debug/dev GUI stuff. This is primarily of benefit in game development, which is where imgui arose and where the vast majority of dear-imgui users work. Once you have it set up, you can place code to create GUI elements anywhere within your application, allowing you to place widgets that let you tune values while your code is running in shockingly little time.

It's not really a good fit for standard application development, though. Primarily this is because it is "bring-your-own-rendering-pipeline." If you know how to set up a simple opengl context this isn't all that difficult, but it's not a route that most app devs are going to want to follow (especially because it kind of assumes you are using a game-loop-type architecture based around a framerate). Some people do use it for user-facing UIs, but that's not where its strengths lie.