Immediate Mode GUIs

Miscellaneous Forums/General Discussion/Immediate Mode GUIs

Okay, so it seems to me that all he is doing is moving backwards. The claim seems to be that OOP is bad for GUIs because you have a ton of state information stored for each GUI component and that this state should be coming from the program state instead of the GUI component state. So instead of having a button that knows it's text is "Hello" you have some program variable containing "Hello" and that is passed into the DoButton() function. What he is missing is that you have exactly the same thing going on with objects and it seems a lot cleaner to me. A set of funcitons (methods) that act on a type and type instances keep only the state information they need.

Well isn't that the same thing only forcing you to keep a huge amount of global data? He says the DoButton() function takes an identifier for the button to deal with, that is the point of the Object handle in OOP. So he has basically decided to take a class and rip it all apart putting some code in the UI manager some code in the program state and some code in the event loop.

The upside to this kind of thing is that you get rid of the need for an event system. However this is just as easily accomplished with OOP. iGlass is a perfect example of this. I have my widget objects such as buttons, and instead of having an actual event queue I just call widget.Clicked() to find out if the widget was clicked.

Maybe I don't get it, but this all sounds like someone that wants to code in C instead of C++ for some reason.