Where to start with GUI

[Bludklok]

Well lately I've been focusing a lot on Allegro / C++ and It's starting to get pretty dull for me. So I thought Id take a break from allegro and get into some GUI programming.

Problem is I don't know exactly where to start.

If someone could fill me in on some good tutorials that would be awesome.

[Netwatcher]

I'm looking for some too, If you know some good concept tutorials of how to write a GUI, the nine-sided way preferably.
(not library specific)

[thejahooli]

I would go with C# forms as they are very simple to use. I read Sams Teach Yourself C# because it teaches you C# (if you don't already know it) and how to do Windows Forms and other things in C#.

[Bludklok]

No offense but I prefer to stick with C++. Not interested in any other language until I absolutely need it.

[Netwatcher]

yep, I meant C++ too if u were wondering.

[programmerinprogress]

I've been working on a little something myself lately, it's in its early stages, but it's getting close resembling a GUI.

I'm programming it to work with SDL, at the minute I have buttons working (and different events, depending on whether the mouse is over the button, or if one of the mousebuttons have been clicked, each button gets its own event too!)

I've come up with a few designs for menus, and I've got some pretty neat ideas there, but i'm just trying to keep the code as well structured as possible, and design issues are the main thing holding me back with the complete implementation.

It's nowhere near finished, but the point i'm trying to make is that you can make your own GUI systems from within allegro and SDL (whatever you use) it just takes some planning and co-ordination, the upside is that your own library will be likely to match your own programming conventions, and it shouldnt look too out of place in your final implementation into your code.

I hope you find what you're looking for anyway

[Bludklok]

Creating a GUI in Allegro? I've thought about something like this but it seams it would be 'sloppy'. In other words... using something to do what it wasn't created for.

I could give it a shot I guess. Hell, I already have a decent knowledge of Allegro so minimal learning involved.

[programmerinprogress]

Creating a GUI in Allegro? I've thought about something like this but it seams it would be 'sloppy'. In other words... using something to do what it wasn't created for.

I could give it a shot I guess. Hell, I already have a decent knowledge of Allegro so minimal learning involved.

I'm doing it in SDL lol, I could just imagine that allegro could probably do it too.

Also, it's do-able, you just have to encapsulate it into a bunch of classes, and when you think about, you're probably keeping overhead (nevermind extra DLLs and the like) down to a minimum because they're using the same library, also, you're not limited by what some other library does, if you're not happy with the way a menu works, you can change it!

EDIT: also, i'm not claiming it's an easy task, I've been thinking about it for a few months now, I haven't had time to fully implement it, so I can't say for certain that it's going to work, just bare that in mind

[/disclaimer]

[Moosader]

Creating a GUI in Allegro? I've thought about something like this but it seams it would be 'sloppy'.

Sounds like we're talking about my map editor here. D:

I mean it's fully possible to write a basic GUI (though a pain). It'd probably be cleaner if I did one now that i know how to use Singletons.
I think my main problem was always trying to figure out how to link buttonA to windowB. Should ButtonA belong to WindowB? Should there be some sort of pointer? Should I just have an indexed list of all buttons and windows, and have them reference the index of which window they belong to?

Maybe Gamedev.net has something on the theory of it...

[programmerinprogress]

Creating a GUI in Allegro? I've thought about something like this but it seams it would be 'sloppy'.

Sounds like we're talking about my map editor here. D:

I mean it's fully possible to write a basic GUI (though a pain). It'd probably be cleaner if I did one now that i know how to use Singletons.
I think my main problem was always trying to figure out how to link buttonA to windowB. Should ButtonA belong to WindowB? Should there be some sort of pointer? Should I just have an indexed list of all buttons and windows, and have them reference the index of which window they belong to?

Maybe Gamedev.net has something on the theory of it...

I'm working on an ID system for that, it's still just a thought in my head, but I'm working on ways of distingusing every button on every form and every form in every window, not quite there yet though

[qpHalcy0n]

It just depends on how deep you want to go with this. A very simple, rudimentary implementation would be one where the GUI can ONLY go one level deep so you don't have to manage convoluted ownership privileges and object relationships. However, in general, they key to a good UI is to keep it as *decentralized* as possible. Where the relationships from one "thing" to another "thing" are very loose and easily modified. This normally leads to an object relationship in where there may be 100 or so very small class objects for GUI objects (radio buttons, labels, scroll bars, etc) and the importance is based on their relationship to the parent.

This can be accomplished very easily *IF* you are extremely comfortable with polymorphic design characteristics. So the most important thing to do first, is to figure out what type of THINGS GUI's have. Windows, buttons, radio buttons, labels, title bars (or not?), drop down menus, are these things clickable, non-clickable? Is there an event associated with a click, etc etc. So at the top level it becomes pretty apparent that there are two main distinctions you have to make (there are 2 fundamental broad objects to a UI): The WINDOW, and the OBJECT. The window is nothing, the window is your pretty GUI wrapper that looks nice, can be moved around, can be minimized, maximized, and so forth. This is an easy container to write because it's not really related to other windows, and they're normally see as individual entities. GUI Objects, however, are your buttons, labels, radio buttons, etc... Objects distinguish themselves (normally) from windows in that they are almost ALWAYS tied to "action". They DO something. These actions are easily defined by modifiable and user-specifiable callback functions. For every object, for every type of event ("OnMouseUp", "OnMouseDown", "OnKeyUp", "OnKeyDown", etc) there is SOME event that has to take place. When OBJECTS are created they are registered to a particular callback function that will do something whenever an action that concerns it has taken place.

So THAT relationships requires a little more information about the primary GUI container. Which is simply an interface to the GUI system as a whole....it's the gears that keep everything together. The GUI container contains an extremely fast doubly ended linked list of Window objects. And in turn, all window objects contain an extremely fast doubly ended linked list of Objects. So the relationship is "Windows have Objects and UI has windows". This linked list is sorted from back to front (for transparency purposes), which lends itself well because then automatically the top level window is the active one. When an event comes through (which GUI constantly monitors for mouse clicks and keypresses), the UI container will first look at the top level window to see that you've clicked inside it's bounds (simple bounding box check). If so, the window must search through it's object list to determine if an object owns this action (another bounding box check). The doubly linked list is fantastic for this because you can search from the front forwards and from the back backwards at the same time. You can subdivide this action to happen 4x....you can subdivide that action to happen 8x (divide and conquer)...8 pointers going forwards and backwards can pinpoint a window that has 100 (or more) objects VERY quickly. Anyways, if the mouse click has happened within the bounds of an object, it's callback function is executed and ....something...happens....whatever that may be.

The objects themselves, whether they are radio buttons, buttons, text boxes, list boxes, scroll bars, etc....are ALL derived from a generic base object class. Where every child can redefine render methods, and event methods. Event methods are mouse clicks and keypresses usually. The base class holds everything common to everything that is an object, like x, y, width, height, isVisible, callback func ptr (if it has one...for instance text fields probably wouldnt need one), etc. The relationships between windows and objects is very easily expressed and when creating a window, the UI class returns a handle. Then to create an object you do this via the window object directly: window* myWin = gui->GetWindow(windowHandle); window->CreateButton(new_button). Or indirectly... gui->CreateObject(windowHandle) which assigns an object to a window.

Here is an extremely simple, unoptimized version of kindof what happens there: http://pastebin.com/m5e28cc7b

You'll see as you hash it out, that the best way to represent things in a UI is as arbitrary and decentralized as possible. The UI doesn't KNOW anything about List boxes, or radio buttons, or buttons, or title bars....it only KNOWS about objects. Objects only have meaning given context and in a good polymorphic design, the Object can be a few things Irregardless of WHAT they are they ALL perform action and return back. In this way, it allows for extraordinarily generic code and very generic containers which minimize size and maximize readability.

So that's kindof a rough guide on how we implemented ours. This is what it looks like.



Fullsize: http://s119.photobucket.com/albums/o121 ... titled.png

[programmerinprogress]

I see what you're aiming at there, i've been considering how each form refers to each object, and polymorphism seems like the way to go, by implementing a uniform interface to different objects seems just the ticket

I was first going to keep it simple, firstly buttons, with the option of a caption (which I've already got working to an extent) and forms to house the buttons, but what you talk about seems much more practical, as it would allow the programmer to impement many different objects with much less fuss.

I need to get my best marker out and clean my board

This post has been very helpful, and I've added it to my bookmarks for the meantime.