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...
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)
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...
the profiler I use most (hotspot) definitely looks much cleaner: https://www.youtube.com/watch?v=6ogEkQ-vKt4
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).
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.
