4 ms·

Rather important is the state ImGui keeps around is independent of the number of widgets. (Imgui's inter-frame state is essentially a list of top-level windows,

Rather important is the state ImGui keeps around is independent of the number of widgets. (Imgui's inter-frame state is essentially a list of top-level windows, a list of pressed buttons and the ID of the active/focused widget -- that's enough). This makes ImGui perfect for inserting it into the traversal of complex data structures and ensures perfect synchrony between UI and data. This is an area were classic GUI tooling often struggles; sure it's totally possible to do with e.g. Qt but making a scene graph accessible as a Qt model likely amounts to a few thousand lines of code, but is comparatively trivial with tightly-coupled ImGui code. Embedding GUIs into a 3D viewport is also something these frameworks aren't generally designed to do, but is the easiest way to do it with ImGui. That being said, real GUI frameworks like Qt are a much better choice for 97 % of "end-user tools", because they have all the bells and whistles you do, in fact, want to have in a desktop application (RAD tools, proper layout system, proper menu/action system, accessibility integration, state inspection etc.)

flohofwoe 6y ago
> ... because they have all the bells and whistles... None of that is incompatible with the immediate-mode-UI philosophy though, it's just that this specific UI toolkit (Dear ImGui) is coming from a direction where those things haven't been that important.
- formerly_proven 6y ago
  Oh but it is. A proper menu/action system requires the toolkit to retain all menus and actions; ImGui doesn't do that (and shouldn't, considering all the places you can put a menu), it also requires layered event handling, which ImGui doesn't want to have. Accessibility requires a retained widget tree, which ImGui explicitly doesn't want. Layouts are incompatible with the current immediate mode API (but could be implemented in an immediate mode API given a legion of lambdas), because the size of widgets depends on the size and possibly contents of other widgets; for ImGui this is all fixed when you call Button(), which immediately calculates all vertices and adds them to the drawlist (that's the retained part in ImGui). There are probably many more points.
  - flohofwoe 6y ago
    I still see those mostly as implementation details of this specific library (Dear ImGui), not as problems of the general idea of UIs that are described through an immediate mode API. I'm sure I'm missing a few important details, but what's preventing another library to make the internals more retained while keeping the illusion of an immediate mode UI on the user side of the API (which is the important part). The internal implementation may be much more complicated than what Dear ImGui does, maybe it's necessary to run multiple passes over the UI description to create the layout, etc... but that might be worth it if the programming model remains as simple as it is now.

flohofwoe 6y ago

> ... because they have all the bells and whistles... None of that is incompatible with the immediate-mode-UI philosophy though, it's just that this specific UI toolkit (Dear ImGui) is coming from a direction where those things haven't been that important.

formerly_proven 6y ago
Oh but it is. A proper menu/action system requires the toolkit to retain all menus and actions; ImGui doesn't do that (and shouldn't, considering all the places you can put a menu), it also requires layered event handling, which ImGui doesn't want to have. Accessibility requires a retained widget tree, which ImGui explicitly doesn't want. Layouts are incompatible with the current immediate mode API (but could be implemented in an immediate mode API given a legion of lambdas), because the size of widgets depends on the size and possibly contents of other widgets; for ImGui this is all fixed when you call Button(), which immediately calculates all vertices and adds them to the drawlist (that's the retained part in ImGui). There are probably many more points.
- flohofwoe 6y ago
  I still see those mostly as implementation details of this specific library (Dear ImGui), not as problems of the general idea of UIs that are described through an immediate mode API. I'm sure I'm missing a few important details, but what's preventing another library to make the internals more retained while keeping the illusion of an immediate mode UI on the user side of the API (which is the important part). The internal implementation may be much more complicated than what Dear ImGui does, maybe it's necessary to run multiple passes over the UI description to create the layout, etc... but that might be worth it if the programming model remains as simple as it is now.