The Blender GUI is established through an interplay of multiple parts of the code. I.e. on a high level:
- GHOST – OS dependent code (windows, OpenGL context, device input, etc.)
- Window-Manager – OS independent management of windows, events, keymaps, data-change notifiers, etc.
- Interface (source/blender/editors/interface/) – button drawing, button event handling, layouts, UI tools (e.g. eyedroppers), menus/popups, …
- Editors – screen-layouts (areas & regions – think of these as the sub-windows), editors (e.g. 3D View, Properties, Node Editor, …), gizmo libraries, tools for individual editors, etc. The Python scripts for layout definitions are executed as part of this too.
Of course this is a very simplified look . There are further things involved like file read/write, undo/redo, translations, context, preferences, add-ons…
As for immediate vs. retained mode (I think this relates to the GUI code, not the graphics drawing): One could argue it’s a mixture, but mostly retained. Buttons are defined, the layout engine runs, later on buttons can capture events, respond with state changes and ultimately tell our data system to update data based on that. It’s roughly a MVC design.
However, buttons are still created on the fly. On each redraw, all (non-active) buttons are destructed and the layout is re-constructed almost from scratch. That way, UI definitions (e.g. the Python scripts) can conditionally place items:
if condition:
# Optionally create a button for the data.propname property.
layout.prop(data, "propname")
This is a typical immediate mode characteristic. For retained mode you’d explicitly hide an existing button.
One thing the GUI code is quite “smart” about is reducing redraws: If data changes, a notifier can be sent, that categorizes this change. Different parts of the UI can listen to these notifiers, and tag themselves for a redraw if they care about the category of data. That way, a change in the Dopesheet usually does not cause the Image Editor regions to redraw.
There are some old 2.5 docs on these designs here: https://archive.blender.org/wiki/index.php/Dev:Source/Architecture/.
All of this sounds like a careful designed architecture, and in some ways it is. But much of this is historical. The UI code contains some of the most messy code I know in Blender. It’s a mixture of very old code (literally from the first days of Blender), newer 2.5 designs and years and years of hacks. Nevertheless, I think especially the 2.5 design brought useful concepts to the design. Although I think the way they were implemented is problematic in many cases.