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