4 ms·

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

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.

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.