> 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
    }

> 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.

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.

  while (running) {
    event := get_next_event()
    process_event(event)
    repaint()
  }

IMGUI is just a different API design IMO.

And then what?

With this one innocuous seeming sentence you are hand waving a way a ton of complexity. If you try to implement it you will at least have some respect for toolkit authors.

> IMGUI is just a different API design IMO.

Yes one that is lower level and therefore is fundamentally harder to deal with to get all the things people take for granted in a full blown mature state based GUI toolkit.

You can implement a retained GUI toolkit with IMGUI. Or you can use something already done.

IMGUI eschews this complexity as part of its purpose but it comes with trade offs that limit its use cases.

https://github.com/goodpaul6/imgui-power-saving-example

Of course this is a greatly simplified example, but I can see this extending to any GUI widget that can be represented with a (hierarchy) of rectangles.

When you unsimplify your example then you are reinventing a wheel. A big wheel. It can be done, but it’s a lot of work. It’s actually easier than ever to implement accessibility for instance (assuming you’re ok pulling in a large dependency), but show me an actual example of this done on top of imgui.

Fantastic - “only” 1 to 2 ms (and that’s for simple stuff). Depending on what you’re doing that’s a big chunk. Also time you could be sleeping. Also something you don’t usually have to worry about.

However, my point with linking this library was just to demonstrate that accessibility and IMGUI are not inherently incompatible.

My point with the example I created above was that you don't have to trade away battery life in order to take advantage of the IMGUI paradigm. My secondary point was also to implement the "interactive rectangles" optimization I mentioned above (which only took a few lines of code).

While I agree with you that there are definitely tradeoffs, I don't think the aforementioned ones are necessary.

Once again, all major GUI toolkits and browser are implemented on top of immediate mode graphics APIs, so you continue to beat this straw man argument. Obviously everything is ultimately immediate mode. No one was refuting those points and sorry they’re not particularly informative.

The point is you’re just rearranging where that state lives and who manages it. You’re retaining it somewhere. But your app is not the best place to manage a lot of this state (as even egui itself admits), it belongs in a well tested library.

Once you start using dirty rectangles, someone has to keep track of them. What benefit is it to me to drive when to call the apis for those details?

IMGUI has a certain elegance where your answer to that is to just say fuck it, and that works well for like a game editor. (The point about accessibility was not that it can’t be done but IMGUI rarely gets actually used where this is ever done). Because if your answer isn’t fuck it to all those things than just go get a library to it for you, which will be managing that state.

I think a lot of people pining for IMGUI really just want sane data binding. Which is understandable, but IMGUI is often throwing the baby out with the bath water.

Like honestly read that egui advantages/disadvantages. That’s a lot of cons (that first one woo) for that one pro (which is not even inherent to all retained APIs).

There are so many issues about so called "power saving mode" and several open PRs like https://github.com/ocornut/imgui/pull/5116.

    while (true) {
        redraw();
    }

    while (true) {
        waitForAndProcessNextEvent();
        redraw();
    }

What I am explaining is that in practice you have to use the second code, because of how operating systems work. This can be handled by a windowing library (SDL, GLFW, Sokol), and the adapters for libraries like Dear Imgui, Nuklear, etc. also expect the second code.

There are ways to skip processing events in some OSs, but this is not really advised by OS writers, and in some cases you will get subpar experience, apps that don't close correctly, etc.

I've written an immediate mode GUI for my projects and it's fine for performance. I've written a music player for instance which uses a negligible amount of CPU, it uses slightly more resources than Clementine, my previous music player.

And why reinvent that wheel? Then localization and accessibility while you’re at it?

> it uses slightly more resources than Clementine

That’s an odd flex, Clementine is extremely horrible for CPU usage (compared to nicer looking examples), probably not due to the GUI, but still. foobar2000 with a ton of plugins works better in wine.

You might be surprised! Modern computers are unbelievable fast.

Same thing.

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.

    while (uiEvent = uiGetNextEvent()) {
        uiHandleEvent(uiEvent);
    }

    if (Button("Click Me!")) {
        printf("Button Clicked!");
    }

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).

> [...] 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.

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".

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/672a3520d7537ef4e75...

The result: 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.

Classic example: the Swing library for Java has layout managers, which help panels decide where their children go, and the most "powerful" one is the GridBagLayout, roughly equivalent to HTML tables with extra features and a favorite of GUI builders.

It can be used to make an unmaintainable monster layout of most of a complex window in a single panel, to structure a trivial reusable component that would be easier to write with a simpler layout manager, or to try and design intermediate level components that are self-contained and benefit from general layout configuration, with no guidance at all from the library or from tools.

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.

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 for more detail

I don't use the new Outlook app because MS email apps usually suck compared to what's available elsewhere.

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.