3 ms·
>> 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 th
by 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 agoYou 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).