I want to build a 2D interface and I want it to be really versatile and complete (CheckBoxes, Buttons, EditTextBoxes, etc.). How would you guys organize the whole thing? Any suggestions will be appreciated.

Take a look at HellRizzer's Gul Tutorial, it may help you :)

Otherwise, there's a more complete series of tutorials for DirectX (you should be able to apply the concepts to OpenGL with ease) startting here

I'd also give a good look at GlGooey, its pretty sweet & I am using it in my projects. Version 0.9 is coming out real soon, but at least take a look at these screen shots.

I'm not realy looking for a GUI Library, but rather for some advices on how to do one.
The DirectX turorials gave me some good tip, but I still have some problems on how to manage the instances of the various elements.

Thanks anyway

hmmmm, ok.

Well, IMHO every GUI should have event handlers & event listeners. When you perform an event, the system passes you those events & you should intercept the ones that you want to use & ignore those that you don't. (for example a mouse click or a key-stroke). When you receive an event, an event handler (perhaps the highest level panel or dialog) should pass that event to all its children & to itself to see if anybody wants it. The children might be actual widgets (check boxes, buttons, edit boxes) or another panel/dialog. If something receives an event, it should by default pass it to every child & to itself.

Most GUIs have some sort of layout guide system, so that when you add a widget to a panel/dialog, you either give it an relative position inside that panel OR let the panel place it where it wants to.

Simple GUI organization is 2 abstract classes: panels & widgets. everything falls under those 2 classes. Objects of these 2 types can be parents &/or children. When a object (panel or widget) is told to draw itself, it draws itself & tells all its children to draw themselves.

This is of course on of the most common design patterns:
a tree of parents & children. & I think it works well in many cases & people can understand it easily.

Make sense?

Of course that makes sense.
And that's axactly how I've organized my GUI, but now I've got a problem I'm not able to solve:
How do I get access to a specific Window/Element?
Let's say that during the game I want to change the value of a textBox, how can I get its address (assuming I'm using poiters)?

I thought of giving each window an ID, but then, to find the one I'm looking for I'd have to pass through all the windows 'till I find the right one, and I don't like that very much.
So is there any way to cope with this?

Thats an interesting problem.

I guess I would like to know more about why you need to update part of a GUI during real-time program operation (gameplay).

Now assuming you are not talking about a HUD (heads up display) that is always showing (cus that is not a GUI)... I would try 1 of 2 things.

a) Some sort of event subscriber / event publisher heirarchy. So when something occurs (a player moves, a ship is shot down, anything) it sends information (a string or a number) to anything that wants to receive it, & when your text-box or line-edit receives it... it will simply set it's text to that data.

b) Save the information that is relevent for the GUI during gameplay & then simply reconstruct the GUI with this potentially new information whenever it is supposed to be displayed.

In a nutshell, there needs to be a link between that widget & whatever updates it. & since its not the USER manually updating it... its a special link. Of course, I can't imagine any reason to have so many GUI windows that it becomes in-efficient to save descriptive pointers to each one. You might just have to bite the bullet & hard code this special relationship in. I'm no pro at any of this or even programming in general... so I'd love to hear other's opinions on this topic.

First I want to thank you all for your replies.
I didn't actually know the difference between a GUI and the HUD (I feel stupid saying this), but still, I'm talking about the GUI and not the HUD.
The reason why I'm trying to avoid using descriptive pointers is that I'm trying to build an engine for the GUI, rather than a specific game.

You could map your GUI controls in a... map. Poor choice of words.

Basically you create an association between a key and a value. In this case, your key might be "ChatBox" and the value would be a pointer to GUI object. You can implement this to get rolling with a Binary Tree, and than more sophisticadedly (brilliant word if it doesn't exist) with a Red/Black Tree or AvL tree. Hell, use an std::map if you're into the STL.

Then its just a simple matter of something like this:
CTextBox *pBox = GUIManager::FindControl("ChatBox");
if(pBox != NULL)
pBox->AddText("Another line!");

Should work out splendidly. Look up more on maps or binary search trees if you don't know of them.