hello, things are going at a pretty steady pace in my current project, except my next roadblock is writing some GUI routines. in the beginning i didnt see that it was going to be all that much of a problem, but then i started having scrambled rendering sequences and just messy code. i decided a more complex gui sub-system was requried. ive looked into a few things like wxWindows and Tknker (i think its called that) GTK ... but i decided id just write my own becasue i dont think i need all the functionality that comes with those libs, and im not entirely sure how well they will mingle with opengl. anyways basically i have a few design questions yet again. i want to just call a single render function and that will render the entire gui in correct order, and when i want to create a GUI object i just add it to a list or vector and it will be rendered later. the problem arises with constantly changing text output and eventually text input. if i were to have a single render function call for the gui, text would have to be deleted and then created again in the "text" vector every frame, or i would have to make the vector a map and modify it every frame ... but i dont really like that idea for holding strings. ... and im not sure how else i would do this, keeping in mind i want flexibility and effenciency. can anyone give me a few pointers or things to think about when doing some basic gui programming? thanks for any help in advance.

Well, I am currently working on a GUI system. This is what I did.

I have a GUI manager which creates, draws, deletes and takes input every frame sends it to the controls to see if any of them need it. Each control has all the information to draw and handle input.

So, Lets say the mouse is over a button and the left mouse button is pressed. That frame the manager get the input then send it to each control if one says the mouse is over me and I handled the button press, it stops looking and the manager returns that it handled the input that frame. also the control now has focus, meaning that if lets say its an inputbox if next I send a keypress it will handle this.

I'm not sure how well I explained this. if I can help you more let me know. or if this is unclear.

look here I made this first but did not like how complex it got.
http://www.gamedev.net/reference/articles/article994.asp

Quote:Original post by ekrax
... and im not sure how else i would do this, keeping in mind i want flexibility and effenciency.

can anyone give me a few pointers or things to think about when doing some basic gui programming?

Well the main structure of gui toolkit (the widgets) usually implements a composite design pattern plus a thew other design pattterns but the composite is the main structure. Then there is the event handling mechnisim in c++ i would recommend using a signals & slots design notably boost's signal & slots lib.

If you mean't GUI in the sense of UI for a game in GL, GL rendering then that should be enough. If you mean't cross-platform window GUIs then you would probably also wont to apply the bridge pattern aswell.

For a simple DIY GUI, i think what you really want is a basic Widget class with a virtual Render() function. Then you can inherit from Widget and redefine your rendering on a per-widget basis. Also, from the little GUI experience i've had, it seems common to have the "master widget" (the window or the screen) draw itself, then all of it's registered children. Each child in turn draws it's children, and so on.

virtual void Render() {   ... draw myself ...   foreach child (children) {      child->Render();      }   }

Quote:Original post by leiavoia
For a simple DIY GUI, i think what you really want is a basic Widget class with a virtual Render() function. Then you can inherit from Widget and redefine your rendering on a per-widget basis. Also, from the little GUI experience i've had, it seems common to have the "master widget" (the window or the screen) draw itself, then all of it's registered children. Each child in turn draws it's children, and so on.

virtual void Render() {   ... draw myself ...   foreach child (children) {      child->Render();      }   }

sounds like some degenerate form of composite pattern, structurally the heart of a widget toolkit would like something like (my UML might be alittle wrong but you get the idea):



Of-course that is very simplified and missing some info, an instance of it would either be a tree or restricted form of directed-acyclic graph to permit sharing of leafs.