Immediate-Mode Graphical User Interfaces - 2005

What Hacker News said

Recommends jblow · 2017-03 · on “VS Code uses 13% CPU when idle due to blinking cursor rendering”

I will also say that this is not an academic argument for me; I am in the middle of writing yet another immediate-mode GUI right now, for the game editor I am working on. Every day I am freshly glad that I am doing things as IMGUI instead of RMGUI. Here is a (somewhat old) video explaining some of the motivations behind structuring things as IMGUI: [this video]

Recommends billsix · 2018-10 · on “Qt Design Studio 1.0”

It’s a library for making windows, buttons, etc (called widgets), for windows Linux and macOS. If you’d like to make graphical applications though, I recommend immediate mode frameworks [this video] [LINK] [LINK]

Recommends danhite · 2022-03 · on “Buttons as Finite Automata”

in 2016 Casey Muratori wrote a few words about his old video "IMMEDIATE-MODE GRAPHICAL USER INTERFACES (2005)" -- apparently he'd been using the technique for years by then and had coined the, now commonly used, imgui acronym -- see: [LINK] and if you dive into that video at 16:50 you'll see a very elegant description of minimal state immediate mode button logic; direct time link: [this video]

Recommends WhereIsTheTruth · 2023-12 · on “Dear ImGui: Bloat-free Graphical User interface with minimal dependencies”

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: [LINK] The gaming cheating community is quite creative as well: [LINK] More on that topic: [this video]

Recommends tuckerpo · 2024-01 · on “Immediate Mode GUI Programming”

Casey Muratori of handmade hero fame is one of the original pioneers (potentially the first?) of immediate mode user-interfaces. Check out this lecture/demo from nearly 20 years ago: [this video]

Cites jstimpfle · 2017-08 · on “McCLIM: A GUI Toolkit for Common Lisp”

I've long been very unimpressed by common GUI development models. And also by resulting GUIs themselves - typically not very flexible. I've made a few attempts to find better approaches. But the fundamental problem is that in the end one always ends up with a separate state machine for GUI elements - so the GUI has to be synchronized with the state of the main thread. This is hard to get right, and unflexible in the end. Two days ago I came across the "Immediate Mode GUI" approach. It has some following for example in the games or realtime graphics sector. I think it's nice and very flexible, but could imagine it falls flat for complex interaction models where you just need considerable stat

Cites gameswithgo · 2020-05 · on “ImPlot: Advanced 2D Plotting for Dear ImGui”

ImGui is a fantastic, and much beloved C++ library whose primary use is to create debug/level editor UIs in games, but people use it for many other purposes as well, some of them quite complex. It can plug into various renderers prety easily, and bindings exist for many popular languages, like Rust, and Rust. It was inspired by this talk given in 2005 by casey muratori on immediate mode guis: [this video] Neat to see additions like this that can plug into it. The rust joke was on purpose.

Cites smaddox · 2020-08 · on “DearPyGui”

As far as I can piece together, Casey Muratori first described the approach in an early YouTube video in 2005: [this video] The basic approach certainly existed far earlier, though. Early "graphical" command line applications, for example, most likely all took an immediate mode approach. It's just that no one thought it was worth making the distinction until after living through the hell that is retained mode GUI programming. In a way, React (along with other vdom-based GUI frameworks) is another rediscovery of immediate mode GUI techniques, but with more of a functional (reactive) programming influence.