4 ms·

The immediate mode gui is largely a myth, IMHO. The concept of gui fully controlled by program data works well for interfaces consisting of a single button. As

The immediate mode gui is largely a myth, IMHO. The concept of gui fully controlled by program data works well for interfaces consisting of a single button. As soon as we have two buttons, each button has a position, and the positions is the data of the gui itself (retained data), not of the program. Imagine a multi-tab interface - which tab is currently active and has its controls drawn is the property of the gui (retained data), again. An action that can be invoked through a menu and can also be added to a toolbar. The toolbar can be expanded or collapsed. Again, that's data of the gui itself (of the view), not of the program (the model). The currently focused button should be highlighted somehow - the property of the gui again. Selected elements of a list (they should be highlighted). Expanded/collapsed state of a tree widget nodes. Scroll positions. So, the immediate mode guis are interesting and somewhat liberating because they demonstrate one can easily build simple ui without complex widget libs, but the results are limited, and very soon stop being really immediate mode. When evolving, they become reinvented wheels of retained mode guis.

cyber_kinetist 5y ago
All of these functionalities that you have described can b e easily implemented in an immediate-mode UI framework, and in my opinion much easily than retained-mode UI frameworks. (I know this because I have used Dear IMGUI extensively, and have done almost all of the things you’ve said). I think you’re arguing with some fundamental “philosophical” stance on what data should be owned by the user and what data should be owned by the GUI. But I feel that pragmatically immediate-mode GUIs are the most efficient at creating complex interfaces (like the ones you have described). The parts where IMGUi are lacking is in complex flexbox layouting, theming, and animations, which isn’t required in editor-like applications for professionals but might matter with end-user applications.
- throwaway82652 5y ago
  >complex flexbox layouting, theming, and animations The only way to implement those things in an immediate mode framework is to cache a lot of state. I haven't found this to be any easier, once the layout becomes complex enough the amount of information that needs to be cached approaches what it would be in retained mode. Because of this I've also found the performance of immediate mode to be very bad. Especially when it involves: - large pieces of reflowing text (this means no text editors or word processors) - very large datasets in list/tree/column/grid widgets (this means no database editors or spreadsheets) - something like a flexbox, css grid or a constraint-solver based layout (this means no responsive layouts) These are all nice things that don't fit well with those patterns. Without any caching or keying it's functionally equivalent to having a React layout that diffs the entire tree before every redraw. The main use cases for immediate mode appears to only be quick prototyping, and making debugging tools for games and simulators. That's not bad by any means, but I've never seen one that is able to efficiently do complex layouts with large datasets.

cyber_kinetist 5y ago

All of these functionalities that you have described can b e easily implemented in an immediate-mode UI framework, and in my opinion much easily than retained-mode UI frameworks. (I know this because I have used Dear IMGUI extensively, and have done almost all of the things you’ve said). I think you’re arguing with some fundamental “philosophical” stance on what data should be owned by the user and what data should be owned by the GUI. But I feel that pragmatically immediate-mode GUIs are the most efficient at creating complex interfaces (like the ones you have described). The parts where IMGUi are lacking is in complex flexbox layouting, theming, and animations, which isn’t required in editor-like applications for professionals but might matter with end-user applications.

throwaway82652 5y ago
>complex flexbox layouting, theming, and animations The only way to implement those things in an immediate mode framework is to cache a lot of state. I haven't found this to be any easier, once the layout becomes complex enough the amount of information that needs to be cached approaches what it would be in retained mode. Because of this I've also found the performance of immediate mode to be very bad. Especially when it involves: - large pieces of reflowing text (this means no text editors or word processors) - very large datasets in list/tree/column/grid widgets (this means no database editors or spreadsheets) - something like a flexbox, css grid or a constraint-solver based layout (this means no responsive layouts) These are all nice things that don't fit well with those patterns. Without any caching or keying it's functionally equivalent to having a React layout that diffs the entire tree before every redraw. The main use cases for immediate mode appears to only be quick prototyping, and making debugging tools for games and simulators. That's not bad by any means, but I've never seen one that is able to efficiently do complex layouts with large datasets.