Building a menu system

Quote:

Original post by Trienco Only 10min into the vid, but so far it sounds like "get rid of all the elaborate stuff that would create clean and structured code and replace it with a huge-ass spaghetti-code if-else-orgy that only a C-hacking mother could love".

Quote:

Original post by Trienco To answer the other question: no, "immediate mode gui" seems to be the very opposite of event based, because so far it sounds like one huge function asking every single interface widget if it was clicked. But I may (hopefully) be wrong there.

Quote:

Original post by Yann L It's polling every single UI element in a huge loop, while every single event handler of the entire UI is entangled somewhere deep in one huge if/else tree. In other words, IMGUI is a really, really bad idea.

switch (UI::Button(UI_ID, Rect(40, 110, 88, 80))) {    default:        // draw the button's normal state        break;    case UI::State::HOVER:        // draw the button's hover state        break;    case UI::State::CLICK:        // draw the button's clicked state        // act on click event        break;}

Quote:

Original post by CadetUmfer In traditional Retained Mode GUIs, you create controls, query controls' state/data, listen for controls' events, and destroy controls. All of this code is in different places.

//somewhere in your appvoid Game::buildSoldiers() {...}//whereever you setup your menuButton* btn = new Button(10,10, 150, 20, menu);btn->onClick = bind(&Game::buildSoldiers, gameInstance);btn->setImage(xxx);

Quote:

This results in all of the code being in one place,

Quote:

regarding IMGUI, this indeed sounds like a horrible waste if it works as you say

Quote:

Original post by brett01 Is event based menu system a kind of retain mode GUI???can someone help me in how to start writing them.

class Widget {   list<Widget*> children;};

Quote:

Original post by Fingers_What are your thoughts? Is it just a question of aesthetics? I will probably need some callbacks anyway in order to allow more advanced customization of GUI objects (e.g. completely replacing how a button is rendered) but I see this as being a different level of user involvement.

Quote:

Why should a control care how it's drawn? Why should a button care what happens when it's clicked? Why should a textbox care what text is in it?

Quote:

One common thing in all GUIs I know and pretty much the whole core of it: class Widget { list<Widget*> children;}; A widget has a position/size and other widgets inside. A click/mouse move will go through the tree and check what you're over/what was clicked. Child elements are sorted by "z" (top first if you don't care about transparency, bottom first if you do).

Original post by Trienco
So basically IMGUI describes the absense of a GUI, since there is no "entity" that could be considered "the GUI". Everything dynamic about a GUI is replaced by hardcoding everything.

This is not necessarily true. It is quite possible to make the UI functions as scripts and make them dynamic. Blender does this. Every GUI that I've made using Qt and wxWidgets have been hardcoded and not dynamic.

Quote:

Original post by Trienco The fact that you say the app needs to actively poll each element all the time sounds just plain wrong to me. For someone trying to "modernize" his design and programming habits that's like promoting horse carriages over cars, simply because they aren't so damn complicated under the hood (also ignoring that you're not supposed to care about what's under the hood).

Each element is given some CPU time to check if it needs to change state, do some action, render, whatever widgets need to do. This is going to happen in any widget library.

Quote:

Original post by Trienco You also all keep pointing at destroying/cleaning up widgets. Something that has never been an issue in any GUI I used or made, because it's like worrying about cleaning up my local variables on the stack or how my smart pointer will clean up when it goes out of scope. It's done "behind the scenes" and basically "none of your business".

Maybe not destroying/cleaning up, but definitely initialization as a precursor step.

Quote:

Original post by Trienco Back to the original question: Three older tools using selfmade GUIs are still lying around with code. Neither qualifies for "brilliant". -SW D6 tool (somewhat experimental and too closely tied to application objects) -OpenGL MiniGUI (first and least flexible, dialogues need to be hand written) -Graphplan (simplistic just-for-fun bonus gimmick for some assignment) There are endless ways to do it and the first question to ask is: how fancy/flexible/dynamic do I need it to be and will I ever use it again after this project?

Neat examples. There are quite a few ways to implement GUI's. You hit the nail on the head. What are you trying to do and do you want to reuse this capability.

Cheers,

Bob

Quote:

Original post by Scourage This is not necessarily true. It is quite possible to make the UI functions as scripts and make them dynamic.

Quote:

Each element is given some CPU time to check if it needs to change state, do some action, render, whatever widgets need to do. This is going to happen in any widget library.

Quote:

Maybe not destroying/cleaning up, but definitely initialization as a precursor step.

//You could be lazy and just give each event a reference to the object//effectively causing empty classes for most casesstruct EditNameEvent : public Event{   EditNameEvent(const string& oldName, const string& newName);   string oldName, newName;};static const EventFactory::Register<EditNameEvent> dummy(someID);App::onEditName(const EditNameEvent& event){  Player.name = event.newName;}App::App(){  new TextEdit(x,y,w,h,parent,someID);  registerEventHandler(&App::onEditName, this);}App::processEvents(){   while (!eventQueue.empty())   {       handleEvent(eventQueue.front());       eventQueue.pop();   }}TextEdit::onEnterPressed(){   eventQueue.push( EventFactory::create(assignedID) );}

struct EditNameEvent : public Event {   EditNameEvent(const string& oldName, const string& newName);   string oldName, newName;};static const EventFactory::Register<EditNameEvent> dummy(someID);App::onEditName(const EditNameEvent& event) {  Player.name = event.newName;}App::App() {  new TextEdit(x,y,w,h,parent,someID);  registerEventHandler(&App::onEditName, this);}App::processEvents() {   while (!eventQueue.empty()) {       handleEvent(eventQueue.front());       eventQueue.pop();   }}TextEdit::onEnterPressed() {   eventQueue.push( EventFactory::create(assignedID) );}

[/quote]

All of that looks like this for me:

UI::TextBox(UI_ID, Player.name, x, y, w, h);//in my main loopUI::Tick(dt);

There is no callback because the Textbox edits the model (Player.name) directly. So there's no events. No event types. No event factory to create them. No event queue to hold them.

To me, your constant quest to abstract away control flow and turn it into types and callbacks is more confusing and unnecessarily complex for a game UI.

It's similar to the scene graph argument. Some people swear by a retained-mode scene graph. :shrug:

Original post by CadetUmfer
All of that looks like this for me:

UI::TextBox(UI_ID, Player.name, x, y, w, h);//in my main loopUI::Tick(dt);

[/quote]

Well, you are conveniently leaving out all the code and logic you obviously didn't encapsulate away in a GUI library. In the same vein I could post the code for the next smash hit video game: while(1) update();

Your tick function contains some interesting parts, especially the part where you poll all your objects, how you determine if it was clicked (there must be _some_ common code, unless you copy/paste endless amounts of "if mouse inside me and button down"-code into a gazillion "updateTextBox735()" functions).

Is it really less code, just because you replace the above registrations with switch() here, if() there and a potentially loooooooooong UI::Tick function?