My point isn't that you can't make them work for non-trivial cases, after all as long as you can draw something on screen you can do pretty much anything. The point is how well that is done.
For example from a quick look at the code it looks like this project needs to draw in a bunch of unrelated to each other libraries just to get some basic GUI functionality you'd find even in toolkits from the 80s provide (e.g. drawing text or using file dialogs).
And check these sources [0] and [1], this is doing at least as much bookkeeping as in a "retained" GUI toolkit - except it also has to do things that such a toolkit would do automatically, like explicitly drawing the widgets [2]. People at the past were complaining how tools like Visual Basic were mixing presentation and logic, yet the worst you could do in these tools is to have the logic in event handlers (...which if you think a bit about it at least that does make a bit of sense), yet here is actual application logic being part of the drawing code in [3] (this is inside a method View::DrawPlayback, scroll a bit upwards to find it).
Now sure, someone might say that this isn't the best example of immediate GUIs... but this is the one that was brought up as a good example. And TBH all it convinced me is that if (for some reason) i had to use ImGui (the library), to spend some time building a retained GUI wrapper around it :-P.
> , there's no question that immediate mode UIs also work well
I sincerely hope no one looks at the screenshot on that page and thinks "this is something that works well". This UI screams "I've been made that way because that was the easiest way in the tool I'm built with" (which is bad - good tools should not dictate the form of the resulting product)
>I sincerely hope no one looks at the screenshot on that page and thinks "this is something that works well". This UI screams "I've been made that way because that was the easiest way in the tool I'm built with"
That's where you'd be wrong. Profilers traditionally have looked like this regardless of the tool/GUI lib/GUI paradigm they'd been made with.
It's the domain need (to show lots of information, graphs, timelines, stack trees, etc, to compare) that asks for this...
How would a profiling tool UI need to look differently in your opinion?
And why do you think the UI looks that way because of restrictions of the UI framework?
I'm quite sure if the UI would have been written with (for instance) Qt or React, it would look exactly the same, because the UI requirements would be the same (minus the different default style). The question is whether this could have been achieved with less, or "cleaner" code (which I doubt).
And how is that different except that the same information is spread over more screen space and hidden inside tabs? White space and tabs also works in immediate mode UIs.
Probably a decent chunk of the perceptual issue you're seeing comes from their choice of font rendering library, which is noticeably "the IMGUI font rendering library", and looks amateurish. This is stb_truetype, which is a very primitive library, but is easy to install and incorporate. The other library is freetype+harfbuzz, which produces higher quality output, faster, and with lower memory. The cost of freetype is that installation is absurdly difficult, the maintainer is offensive, and the code is ancient, unreadable, and architecturally a disaster.
I don't think the chosen GUI library causes the other UI issues you perceive. The author probably hasn't put much time into learning visual design, and thus fell into whatever the UI library supported. But to produce a better one, the author would have had to do a lot more learning and thinking, which is independent of the library choice.
For example from a quick look at the code it looks like this project needs to draw in a bunch of unrelated to each other libraries just to get some basic GUI functionality you'd find even in toolkits from the 80s provide (e.g. drawing text or using file dialogs).
And check these sources [0] and [1], this is doing at least as much bookkeeping as in a "retained" GUI toolkit - except it also has to do things that such a toolkit would do automatically, like explicitly drawing the widgets [2]. People at the past were complaining how tools like Visual Basic were mixing presentation and logic, yet the worst you could do in these tools is to have the logic in event handlers (...which if you think a bit about it at least that does make a bit of sense), yet here is actual application logic being part of the drawing code in [3] (this is inside a method View::DrawPlayback, scroll a bit upwards to find it).
Now sure, someone might say that this isn't the best example of immediate GUIs... but this is the one that was brought up as a good example. And TBH all it convinced me is that if (for some reason) i had to use ImGui (the library), to spend some time building a retained GUI wrapper around it :-P.
[0] https://github.com/wolfpld/tracy/blob/master/server/TracySou...
[1] https://github.com/wolfpld/tracy/blob/master/server/TracyVie...
[2] https://github.com/wolfpld/tracy/blob/d8c1dae9e120c27801e762...
[3] https://github.com/wolfpld/tracy/blob/d8c1dae9e120c27801e762...