6 ms·

Immediate mode GUI is fine for quick and dirty things, but once you start dealing with multiple application views that conditionally show/hide, with branching f

Immediate mode GUI is fine for quick and dirty things, but once you start dealing with multiple application views that conditionally show/hide, with branching flows of any kind, you'll find yourself on a hardline track to reinvent retained mode GUI from scratch just so you can handle the event loop in a sane way. Object oriented, event driven widgets composed into more colored views are really, really good for developing UI. There's a reason every major OS GUI toolkit is this design. If you componentize like you are supposed to--instead of just smashing everything into one form--they work and can be reasoned over with few surprises. The trouble comes from not componentizing things that you should when your current platform doesn't provide the full menagerie of widgets that you'll need. Basically, it you have any kind of input that results in a value that is not just a raw string, you should be building a component for that input: URLs, paths to files, numbers, dates, selectors for picking a set list of structured objects, etc.

flohofwoe 3y ago
Isn't the whole point of immediate mode UIs to get rid of the "event loop" though? > multiple application views that conditionally show/hide The ImGui way of doing this is to conditionally run or not run the code which describes the conditionally shown UI elements. E.g. a simple if (viewShown) { ...code which describes what the view looks like } There are plenty of real-world applications with complex UIs implemented in Dear ImGui which don't seem to have a problem with those things, e.g. see https://github.com/ocornut/imgui/labels/gallery https://github.com/ocornut/imgui/labels/gallery > The trouble comes from not componentizing things... In ImGui, reusable UI components are just code which describes the UI component by calling lower-level ImGui functions and which itself is a new ImGui-style function. It works surprisingly well.
- moron4hire 3y ago
  >> Isn't the whole point of immediate UIs to get rid of the "event loop" though? No, not at all. It's to take explicit control of the event loop. It's right there, you have a loop and the buttons still fire events, you just have to check for them on every iteration of the loop.
  - flohofwoe 3y ago
    You don't have to 'install' event handlers, there are no event objects, and there's no event loop like: while (uiEvent = uiGetNextEvent()) { uiHandleEvent(uiEvent); } ...and it would never enter my mind to call this an 'event handler': if (Button("Click Me!")) { printf("Button Clicked!"); } One very nice side effect of this immediate mode style code is that it 'runs on a linear timeline', e.g. you can step through the code in a debugger without having to put breakpoints inside 'event handlers'. How all this is implemented inside the immediate mode UI framework isn't relevant. The 'immediate mode idea' is only about the user-facing code which describes the UI, not the internal implementation (those can vastly differ, and could even manage a 'retained mode' widget tree under the hood).
- deleted 3y ago
  [deleted]
- epcoa 3y ago
  If your entire system ran with immediate mode GUIs your performance would either be in the toilet or battery life would be destroyed (or both). They’re great for games and GPU where you’re in a for a pound anyway. There are some music apps that use it and it’s horrible if you’re on a laptop. No I don’t want to consume a couple watts when I should be idling because the entire screen is being repainted doing nothing. Makes electron seem nice.
  - goodpaul6 3y ago
    I'm not sure the perf/battery life tradeoff is a necessary aspect of immediate mode UI. while (running) { event := get_next_event() process_event(event) repaint() } You could just have get_next_event block until there is a meaningful event that occurs (e.g. mouse click). You could even have your UI report "interactive" rectangles to the event layer to prevent it from producing e.g. mouse move events that are irrelevant. IMGUI is just a different API design IMO.
    - kvemkon 3y ago
      > IMGUI is just a different API design IMO. There are so many issues about so called "power saving mode" and several open PRs like https://github.com/ocornut/imgui/pull/5116 https://github.com/ocornut/imgui/pull/5116.
    - n2d4 3y ago
      If you do that, you have an event loop again (like in the OP), which your comment's grandparent was trying to get rid of (and your parent explained to them why they can't).
      - whstl 3y ago
        In practice there is always a loop. I believe the point flohofwoe was making is that with an immediate UI you don't have to even touch events in your immediate UI code (they are abstracted away, if needed, in a pretty clean manner, IMO), so there's no need to do anything to get a "sane event loop". I might be wrong about what's his point though.
jesse__ 3y ago
I'm sorry, but I've got to call this out as woefully inaccurate. > [...] so you can handle the event loop in a sane way. The whole point of an immediate-mode framework is that the call-stack acts as the event loop. You run through your UI code, and if a thing was interacted with on the previous frame, you just handle it. What about that setup is not sane? > [...] instead of just smashing everything into one form [...] There is nothing about immediate mode that makes it more or less able to have everything 'smashed into one form'. You can do that just as well with your retained-mode framework of choice. > The trouble comes from not componentizing things This also has nothing to do with the immediate vs. retained mode discussion. You could just as easily make a giant mess in retained-mode by not making reusable components. > once you start dealing with multiple application views that conditionally show/hide, with branching flows of any kind [..] In my spare time, I work on a game engine whose editor/debug UI is completely immediate mode. There are discrete views into nearly everything in the engine. Entity data, a color picker, memory and CPU performance views, asset viewers/pickers, a terrain editor with like 10 modes.. you name it. There are plenty of conditionally shown views. There is plenty of 'componentizing' of things going on. The editor UI is in the neighborhood of 10k lines, most of which is generated. If that's below your bar for quick-n-dirty, maybe we have different opinions on what qualifies.
- moron4hire 3y ago
  >> The editor UI is in the neighborhood of 10k lines, most of which is generated. I mean, this sounds like you've created a retained mode DSL that gets compiled into immediate mode. And yes, 10 KLoC is definitely a small project, especially when "most of which is generated".
  - jesse__ 3y ago
    > this sounds like you've created a retained mode DSL that gets compiled into immediate mode Nope, I wrote a template-metaprogramming language, which generates the UI. There's nothing retained-mode about it. The source code: https://github.com/scallyw4g/bonsai/blob/672a3520d7537ef4e754e0dc2535f2df5817c99a/src/engine/editor.h#L81 https://github.com/scallyw4g/bonsai/blob/672a3520d7537ef4e75... The result: https://github.com/scallyw4g/bonsai/blob/master/generated/do_editor_ui_for_compound_type_world_chunk.h https://github.com/scallyw4g/bonsai/blob/master/generated/do... > And yes, 10 KLoC is definitely a small project I said it cleared the bar for quick-n-dirty. I agree it's not a large amount of code.
merb 3y ago
> There's a reason every major OS GUI toolkit is this design. Ehh.. the latest os ui toolkit is uwp which lost to react native (a im gui) and it does not look that winui3 will fix that. Linux has two major gui libraries, both are probably only used by enthusiasts and not by enterprises which prefer to target react native (mostly for different reasons tough) Drawing components won because the object oriented world of gui design sucks and because it’s hard to target multiple systems. All modern ui libs use a kind of immediate mode. It’s way easier to understand and you do not need to explain why you need to use mvvm.
- jayd16 3y ago
  React native is an imgui? Aren't views defined with a declarative language similar but distinct from html?
  - kragen 3y ago
    yes, it is yes, they usually are, which is irrelevant to the question of whether react is retained-mode or immediate-mode please see https://news.ycombinator.com/item?id=39010462 https://news.ycombinator.com/item?id=39010462 for more detail
- rstat1 3y ago
  For desktop use, Qt is quite widely used pretty much everywhere. I only ever see React Native being used so a company can claim to have a "native" mobile app.
  - merb 3y ago
    Im not sure if you used windows in the last 5 years than. Heck the new outlook is a react native kind of ui.
    - rstat1 3y ago
      All the stuff I use on Windows (save for Discord) is a real native app. I don't use the new Outlook app because MS email apps usually suck compared to what's available elsewhere.
jcranmer 3y ago
The way I think about it, GUIs come down to a few basic principles: 1. Program data is primarily hierarchical. This means that you can generally compose a view for a data item out of smaller views down to a basic set of elements (e.g., text display, combo box, etc.), and also means that you can generally ignore all data not included that view. There are some cases where this breaks down (tables really stretch it, for example), but it definitely holds for most GUIs. 2. UI also has state independent of program data. Immediate GUIs to a degree go ha-ha-there's-no-such-thing and make it somebody else's problem, but this state has to be retained somewhere. However, it's not exactly a binary choice between UI and program state--something like whether or not a checkbox is checked can go either way (I think of it as UI state because I tend to deal in batch-mode programs, where what is going to happen is the UI state will be distilled into the input to code I execute whose results will be displayed). 3. Conversion of program state to UI needs to be lazy--you don't want to forcibly map every element in a list immediately to UI widgets. The best example of this, of course, is the scrollbar. 4. Whereas program state is hierarchical, UI state is far less hierarchical in nature. That is to say, the state of a UI element may influence the display of a UI element in a completely different tree. The difference between immediate and retained mode is less important than it might seem at first glance. If your UI is simple and largely static, hierarchical application of canned elements, then both an immediate and a retained mode interface will end up looking roughly the same in terms of code. If your UI is complex and deals with heavy and very impure state, it again doesn't matter all that much, because you're going to have to maintain that state all yourself anyways. As a programmer who hates writing GUI code, though, all I really want is a thoroughly complete set of widgets (the ontology of UI is pretty standard, after all). I don't really care about immediate mode or retained mode, I just want a path that lets me easily render my program state with the minimum hassle. And quite frankly, it seems like the only GUI toolkits that make it as far as figuring out how to include a lazy table widget are the retained mode GUIs, which maybe suggests something about immediate mode GUIs.

flohofwoe 3y ago

Isn't the whole point of immediate mode UIs to get rid of the "event loop" though? > multiple application views that conditionally show/hide The ImGui way of doing this is to conditionally run or not run the code which describes the conditionally shown UI elements. E.g. a simple if (viewShown) { ...code which describes what the view looks like } There are plenty of real-world applications with complex UIs implemented in Dear ImGui which don't seem to have a problem with those things, e.g. see https://github.com/ocornut/imgui/labels/gallery https://github.com/ocornut/imgui/labels/gallery > The trouble comes from not componentizing things... In ImGui, reusable UI components are just code which describes the UI component by calling lower-level ImGui functions and which itself is a new ImGui-style function. It works surprisingly well.

moron4hire 3y ago
>> Isn't the whole point of immediate UIs to get rid of the "event loop" though? No, not at all. It's to take explicit control of the event loop. It's right there, you have a loop and the buttons still fire events, you just have to check for them on every iteration of the loop.
- flohofwoe 3y ago
  You don't have to 'install' event handlers, there are no event objects, and there's no event loop like: while (uiEvent = uiGetNextEvent()) { uiHandleEvent(uiEvent); } ...and it would never enter my mind to call this an 'event handler': if (Button("Click Me!")) { printf("Button Clicked!"); } One very nice side effect of this immediate mode style code is that it 'runs on a linear timeline', e.g. you can step through the code in a debugger without having to put breakpoints inside 'event handlers'. How all this is implemented inside the immediate mode UI framework isn't relevant. The 'immediate mode idea' is only about the user-facing code which describes the UI, not the internal implementation (those can vastly differ, and could even manage a 'retained mode' widget tree under the hood).
deleted 3y ago
[deleted]
epcoa 3y ago
If your entire system ran with immediate mode GUIs your performance would either be in the toilet or battery life would be destroyed (or both). They’re great for games and GPU where you’re in a for a pound anyway. There are some music apps that use it and it’s horrible if you’re on a laptop. No I don’t want to consume a couple watts when I should be idling because the entire screen is being repainted doing nothing. Makes electron seem nice.
- goodpaul6 3y ago
  I'm not sure the perf/battery life tradeoff is a necessary aspect of immediate mode UI. while (running) { event := get_next_event() process_event(event) repaint() } You could just have get_next_event block until there is a meaningful event that occurs (e.g. mouse click). You could even have your UI report "interactive" rectangles to the event layer to prevent it from producing e.g. mouse move events that are irrelevant. IMGUI is just a different API design IMO.
  - kvemkon 3y ago
    > IMGUI is just a different API design IMO. There are so many issues about so called "power saving mode" and several open PRs like https://github.com/ocornut/imgui/pull/5116 https://github.com/ocornut/imgui/pull/5116.
  - n2d4 3y ago
    If you do that, you have an event loop again (like in the OP), which your comment's grandparent was trying to get rid of (and your parent explained to them why they can't).
    - whstl 3y ago
      In practice there is always a loop. I believe the point flohofwoe was making is that with an immediate UI you don't have to even touch events in your immediate UI code (they are abstracted away, if needed, in a pretty clean manner, IMO), so there's no need to do anything to get a "sane event loop". I might be wrong about what's his point though.

jesse__ 3y ago

I'm sorry, but I've got to call this out as woefully inaccurate. > [...] so you can handle the event loop in a sane way. The whole point of an immediate-mode framework is that the call-stack acts as the event loop. You run through your UI code, and if a thing was interacted with on the previous frame, you just handle it. What about that setup is not sane? > [...] instead of just smashing everything into one form [...] There is nothing about immediate mode that makes it more or less able to have everything 'smashed into one form'. You can do that just as well with your retained-mode framework of choice. > The trouble comes from not componentizing things This also has nothing to do with the immediate vs. retained mode discussion. You could just as easily make a giant mess in retained-mode by not making reusable components. > once you start dealing with multiple application views that conditionally show/hide, with branching flows of any kind [..] In my spare time, I work on a game engine whose editor/debug UI is completely immediate mode. There are discrete views into nearly everything in the engine. Entity data, a color picker, memory and CPU performance views, asset viewers/pickers, a terrain editor with like 10 modes.. you name it. There are plenty of conditionally shown views. There is plenty of 'componentizing' of things going on. The editor UI is in the neighborhood of 10k lines, most of which is generated. If that's below your bar for quick-n-dirty, maybe we have different opinions on what qualifies.

moron4hire 3y ago
>> The editor UI is in the neighborhood of 10k lines, most of which is generated. I mean, this sounds like you've created a retained mode DSL that gets compiled into immediate mode. And yes, 10 KLoC is definitely a small project, especially when "most of which is generated".
- jesse__ 3y ago
  > this sounds like you've created a retained mode DSL that gets compiled into immediate mode Nope, I wrote a template-metaprogramming language, which generates the UI. There's nothing retained-mode about it. The source code: https://github.com/scallyw4g/bonsai/blob/672a3520d7537ef4e754e0dc2535f2df5817c99a/src/engine/editor.h#L81 https://github.com/scallyw4g/bonsai/blob/672a3520d7537ef4e75... The result: https://github.com/scallyw4g/bonsai/blob/master/generated/do_editor_ui_for_compound_type_world_chunk.h https://github.com/scallyw4g/bonsai/blob/master/generated/do... > And yes, 10 KLoC is definitely a small project I said it cleared the bar for quick-n-dirty. I agree it's not a large amount of code.

merb 3y ago

> There's a reason every major OS GUI toolkit is this design. Ehh.. the latest os ui toolkit is uwp which lost to react native (a im gui) and it does not look that winui3 will fix that. Linux has two major gui libraries, both are probably only used by enthusiasts and not by enterprises which prefer to target react native (mostly for different reasons tough) Drawing components won because the object oriented world of gui design sucks and because it’s hard to target multiple systems. All modern ui libs use a kind of immediate mode. It’s way easier to understand and you do not need to explain why you need to use mvvm.

jayd16 3y ago
React native is an imgui? Aren't views defined with a declarative language similar but distinct from html?
- kragen 3y ago
  yes, it is yes, they usually are, which is irrelevant to the question of whether react is retained-mode or immediate-mode please see https://news.ycombinator.com/item?id=39010462 https://news.ycombinator.com/item?id=39010462 for more detail
rstat1 3y ago
For desktop use, Qt is quite widely used pretty much everywhere. I only ever see React Native being used so a company can claim to have a "native" mobile app.
- merb 3y ago
  Im not sure if you used windows in the last 5 years than. Heck the new outlook is a react native kind of ui.
  - rstat1 3y ago
    All the stuff I use on Windows (save for Discord) is a real native app. I don't use the new Outlook app because MS email apps usually suck compared to what's available elsewhere.

jcranmer 3y ago

The way I think about it, GUIs come down to a few basic principles: 1. Program data is primarily hierarchical. This means that you can generally compose a view for a data item out of smaller views down to a basic set of elements (e.g., text display, combo box, etc.), and also means that you can generally ignore all data not included that view. There are some cases where this breaks down (tables really stretch it, for example), but it definitely holds for most GUIs. 2. UI also has state independent of program data. Immediate GUIs to a degree go ha-ha-there's-no-such-thing and make it somebody else's problem, but this state has to be retained somewhere. However, it's not exactly a binary choice between UI and program state--something like whether or not a checkbox is checked can go either way (I think of it as UI state because I tend to deal in batch-mode programs, where what is going to happen is the UI state will be distilled into the input to code I execute whose results will be displayed). 3. Conversion of program state to UI needs to be lazy--you don't want to forcibly map every element in a list immediately to UI widgets. The best example of this, of course, is the scrollbar. 4. Whereas program state is hierarchical, UI state is far less hierarchical in nature. That is to say, the state of a UI element may influence the display of a UI element in a completely different tree. The difference between immediate and retained mode is less important than it might seem at first glance. If your UI is simple and largely static, hierarchical application of canned elements, then both an immediate and a retained mode interface will end up looking roughly the same in terms of code. If your UI is complex and deals with heavy and very impure state, it again doesn't matter all that much, because you're going to have to maintain that state all yourself anyways. As a programmer who hates writing GUI code, though, all I really want is a thoroughly complete set of widgets (the ontology of UI is pretty standard, after all). I don't really care about immediate mode or retained mode, I just want a path that lets me easily render my program state with the minimum hassle. And quite frankly, it seems like the only GUI toolkits that make it as far as figuring out how to include a lazy table widget are the retained mode GUIs, which maybe suggests something about immediate mode GUIs.