Hi

I am pondering how I should implement a GUI class. I figured I should have a root parent and then have child windows attached to that root parent. But how should the parent and the child be connected? Should I "new" each child and put a pointer to the child on the vector? Should the vector itself be a pointer to a vector which can hold children? What makes more sense, heap or stack or something in between?

struct GuiWindow
{
WinParam parameters;
std::vector<WindowObject> WindowObjects;
std::vector<GuiWindow> ChildWindows;
}

struct GuiWindow
{
WinParam parameters;
std::vector<*WindowObject> WindowObjects;
std::vector<*GuiWindow> ChildWindows;
}

struct GuiWindow
{
WinParam parameters;
std::vector<WindowObject> *WindowObjects;
std::vector<GuiWindow> *ChildWindows;
}

struct GuiWindow
{
WinParam parameters;
std::vector<*WindowObject> *WindowObjects;
std::vector<*GuiWindow> *ChildWindows;
}

struct GuiWindow
{
WinParam parameters;
std::vector<WindowObject*> WindowObjects;
std::vector<GuiWindow*> ChildWindows;
}

class WindowObject //Also often called 'widgets', but not always.
{
    public:
    WindowObject(WindowObject *parent);

    //Overridable function to handle a mouse click. The default implementation forwards it to whatever child window
    //at that location, and that child returns true if it handled the event, or false if it ignored it, letting
    //the event propagate to the bottom of the child hierarchy (which is visibly the widgets 'on top' of everything), before
    //bubbling back up through all the parent windows.
    virtual bool onMouseClick(const MouseClickEvent &mouseClick);
    virtual bool onMouseMove(const MouseMoveEvent &mouseMove);
    virtual bool onKeyPress(const KeyPressEvent &keyPress);
    virtual bool onShow();
    virtual bool onHide(); 
    
    //...and a half-dozen other events.

    private:
    unsigned int posX, posY; //Relative to the parent's position.
    unsigned int width, height;
    std::vector<WindowObject*> children; //Any buttons, sub-windows, pop-up windows, side-panels, text edits, text objects, image objects, etc...
};

You might also consider going with some form of immediate mode GUI, and doing away with the class structure altogether.

It's not necessarily a panacea, but it's a concept well worth wrapping your mind around. IMGUIs also tend to be much simpler than traditional retained GUI frameworks, especially for small-scale projects.

This made no sense to me at all. Is there a tutorial that explains this concept better?

The Sol IMGUI tutorials walk you through creating some, using SDL.

Looking into IMGUI I find it hard to belive it is "that much" simpler then the standard RMGUI as it claims. Because every button, window, slide, label and list still needs to be defined somewhere. IMGUI just puts that away and says "it is not my responsibility", but then IMGUI is not a GUI is it? It is just a wrapper for a sprite or text drawcall...

If I were to try and roll my own IMGUI class I still need a place that retains all info on the layout of the GUI, what textures different buttons have etc. And what better place to keep that information other then inside the IMGUI class? Then the IMGUI class suddenly transforms into a RMGUI class.

I just don't get it is what I am trying to say :p

So... how does people do IMGUI in terms of defining the gui layout? Say I have windows that contain 20 buttons, a health bar, a text edit box, some labels, check boxes and so on. Where would I go about saving where each of these wedgets gets placed on the screen? I surely can't have each widget as a global or static variable? So is it implied that the IMGUI class should contain a std::vector<widget*> which holds this info?

I think it is just too easy to claim the IMGUI class is not responsible for saving this data. What am I missing here?