求区分两类UI框架API范式的专业术语（非即时/保留模式）

Ah, this is a great question—I’ve run into this exact terminology gap before! The two API paradigms you’re describing have standard names focused on who controls the application’s core execution flow:

The Two Standard Terms #

• Explicit Event Loop (or "Event Loop as Library"): This covers the Win32, Xlib, SDL-style APIs you mentioned.
• Managed Event Loop (or "Event Loop as Framework"): This applies to Qt, GTK, wxWidgets, Swing, Tk, and similar toolkits.

Let’s break each down with your examples in mind:

Explicit Event Loop (Event Loop as Library) #

In this model, you’re sitting at the top of the call stack—you write the main loop, and explicitly call functions like GetMessage(), XNextEvent(), or SDL_PollEvent() to pull events from the system’s queue. There’s no framework taking over; every step of the application’s execution is your responsibility.

This requires a deeper dive into low-level system mechanics, but it gives you unfiltered control over timing, resource allocation, and how events are processed. It’s the go-to choice for:

• Game engines where precise frame timing and tight integration between input, rendering, and logic is critical
• Resource-constrained applications (like those targeting 80286 CPUs) where even a small amount of framework overhead could break functionality
• Custom tools that need to interleave event handling with other high-priority, non-GUI tasks

Managed Event Loop (Event Loop as Framework) #

Here, the framework owns the core event loop. Your job is to set up your application: initialize components, register event handlers (like button click callbacks), and then hand over control to the framework via a dedicated entry point—think QApplication.exec(), gtk_main(), Fl::run(), or the IMPLEMENT_APP(wxAppSubclass) macro.

The framework runs the loop (usually in the main thread, though some toolkits use background threads for specific tasks) and automatically dispatches events to your registered handlers. This abstracts away the low-level event queue work, letting you focus on building your application’s functionality rather than managing execution flow. It’s perfect for most GUI apps where rapid development and adherence to platform conventions are key.

Critical Distinction from Immediate/Retained Mode #

As you correctly noted, this is not the same as the immediate vs retained mode GUI split. A retained mode toolkit could theoretically expose an explicit event loop (though that’s uncommon), and an immediate mode UI (like ImGui) can easily be embedded within a framework-managed loop by hooking its render calls into a widget’s paint event. The event loop paradigm is about who controls the application’s main flow, while immediate/retained mode is about how UI state is stored and rendered.

内容的提问来源于stack exchange，提问作者ssokolow