Since you want to be able "to widget" any variable in the whole application, then you need access to the GUI instance (i'm using C++ here) in all of the code. Meaning you need to either pass the GUI around to all parts of the code as a parameter, make a singleton or a global. People advise against the last two options. How would you get access to the GUI from any part of the application?
Good point there. The good thing is that the main loop (the "update frame" method, not the "render frame") should have access to all data that is dealt with. So you would define your IMGUI object there. The bad part is all the private variables of your data. In the example above, if the softbody object has SetDamping() and GetDamping() methods around a private variable, it just won't work as easily. I can recall making variables public for that purpose, which is ugly. Maybe some pedantic OO-guru may come up with some generic-template-based-operator-overloading-behind-the-back-reflection-super-solution to this to make it look like OO where it isn't. I didn't bother tho.
Also, before rendering the scene there is alot of stuff to be done. And in IMGUI it is before you render you pass through a variable you want to display with a widget. So in my mind, the IMGUI needs carry with it a render target and make a scene for each widget you want to draw... How would this then affect performance when the GUI keps using drawcalls in all parts of the application?
"Make a scene" sounds like setting up a scene graph for a widget Well, It makes use of a pretty regular graphics class which provides basic drawing for OpenGL. Nothing too complex here. It uses the main (and only) OpenGL context. And its based on vertex arrays, all draw calls put vertices/colors into point/line/triangle arrays. Just for the record, its a cheap and hackish port of the http://code.google.com/p/glcanvas/ library. The 2D part of it. Strings are rendered into textures and glDeleteTexture'd when the string is not drawn for 5 frames.
The next logical solution is to defer the draws until the scene is drawn in the render code. Piling up the drawcalls into a vector to be drawn at a later time. So yet again we need to carry retained data for each widget in the GUI. That means a copy of any value, text, textures and layout info for each widget to complete the defered rendering. Only the functionality of the widget is immediate in where you place the code.
Well, I wouldn't say that filled up vertex and text arrays is a copy of the variables and its layouts. So "No" to that part (in my case! you may do it differently).
However, the last part is so true and is outing you as someone who has fully understood the concept. Only the interface to the GUI is immediate! Yes! In fact, it is up to you how much data is stored "behind the scenes". It is implementation details. It may even store more data than a retained mode GUI.