Struct with child struct
You call the function every frame, and that's your button. No initialisation, no clean-up, and no callbacks. In many cases, that really is simpler.
Around 3 years ago I have made my own IMGUI, heavily based on sol's tutorials mentioned above, but using pure OpenGL instead of SDL. It has no fancy stuff, just the usual suspects of widgets. Button, Slider, Checkbox, Group box. ID's are hardcoded, and for the layout I have a rectangle object that I offset by its height or width via rect.NextRow() or rect.NextCol(). Its pretty clear to me that this is most useless for any larger project. However, it really shines when I quickly want to try something out. Some voronoi library, a new particle system or whatever comes along while surfing the web. I simply include my IMGUI library and can most effortlessly expose variables to the GUI. Lets say I have a softbody simulation going on, and I want to have the damping variable accessible, I just put something like
gui.rect.NextRow();
gui.Slider(109, &damping, 1.0f, 50.0f, "Damping");
into the code and I am done. Nothing more neccessary. For me it kinda feels a little bit like the console for OpenGl based applications. It is ridiculously simple, but comes in too handy to be neglected
cheers, boogi
Thanks boogi for your input.
I have some more questions if you don't mind to answer.
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?
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?
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.
Is there a solution to this I don't see here?
[quote name='Tispe' timestamp='1358450824' post='5022615']
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?
[/quote]
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.
[quote name='Tispe' timestamp='1358450824' post='5022615']
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?
[/quote]
"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.
[quote name='Tispe' timestamp='1358450824' post='5022615']
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.
[/quote]
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.