Updated the Makefile to use Allegro 5.0. Also added a generic rule to build object files from source files in the src/ directory. Don't know though how to abstract the mapping of object files to the respective output so ${LIBOBJS} is still static (and updated).

** APPEND **

Just pulled the UTF-8 updates in. Now the program doesn't seem to respond to the close button or ESC key. I don't know if it's a bug in the program or in the build system, but naturally I blame the program.

Unfortunately, between the two of us we borked it. It should be fixed again though on my side. You seemed to have replaced tabs with spaces when you merged. That's generally a bad idea because Makefile's use tabs as part of their syntax. AFAIK, those tabs are necessary (I use spaces for indentation too, but have Vim configured to use tabs in Makefiles). I also broke the Makefile while trying to rearrange things, but I think I have it fixed again. I've added a branch on my end for maintaining the Makefile. A script counts the objects in the library and compares it to the source files in src/. Not the cleanest way to go about things, but it gives me peace of mind that I have them all. Hopefully I don't screw up and merge it into master.

I updated again, but when I run it all I see is a background image. It doesn't seem to respond to input though (ESC, 1, 2, and 3 do nothing). I can't even close the window with the close button any more. I need to ^C from the terminal I launched it from to stop it.

You can pull it any time you want. I've been pulling from you without even checking GitHub. As a general rule, a pull request is just a way to communicate to somebody that you have something you'd like them to merge with. If you know somebody else has something that you want to merge with though you can just do it.

If I had the knowledge to do my own makefile I would do it, I'm actually reading a tutorial about it.

When I try to compile it with my IDE I just get the object files (.o). shouldn't be a library files (.a)? inside the lib folder?

But now I'm trying to compile the new version and I'm getting: "Makefile:33: *** missing separator. Stop." (I just read what might be happening)

Yes I use Linux too (Trisquel) but when I distribute my software I would like to say:
"Windows Version"
"Linux Version"
Why to learn one OS if I can learn two?

EDIT:

And now I'm trying to compile it with my IDE and I get:

Assertion failed: skin, file C:\axilmal\src\algui_widget.c, line 2230

EDITED AGAIN:

I got it!! I got it!!

And why there is a font file?

EDITED AGAIN:

In the file:"algui_skin.h" you wrote "an algui skin is nothing more an an Allegro config file with resource strings and a path." just if you want to change it...

Well, really we were talking about C, because that is what you are writing your library in.

This leads right back to the extra code I posted before. Making arbitrary structs just to reference data, making arbitrary un-reuseable functions, and making the user set callbacks if he wants to do anything useful with your GUI's widgets.

Signals and slots may be a more powerful and versatile mechanism in C++, but I still think events are more useful than callbacks in C. It is rather rare that you need to have reaction code immediately follow a widget event, and thus you rarely need to have callbacks. I think that you are just making things more complicated than they should be, but it's your choice.

This is not true, and it is also not a problem.

If you have composite widgets, then set the contained widgets parent pointer to the container address. When QueueUserMessage is called from the contained widgets, their parent(the container) gets QueueUserMessage called and it can check the messages before passing them on to its parent. This way, a scrollbar can check a scroll button's messages and set the slider widget's value accordingly.

The only requirement is to set a parent pointer, and to monitor the child's messages with QueueUserMessage. It works very well in my GUI.

Then why do you post c++ examples and comments on how you would do it in c++?

Let's not mention c++ again then. We don't need to be confused by a different language.

You can always use callbacks to post events to the main event queue.

And you can also make your data global variables instead of declaring them as local variables in a function, so as that you don't need to make arbitrary structs.

There is no practical difference between declaring variables in function 'main' and outside of 'main' anyway.

It's not rare at all. Take a text box, for example: immediate callbacks are needed so as that the text box controls which text goes in the widget. The alternative is to code a parser which will be used by the text box, something that is extremely more difficult to do.

Events are more complicated than callbacks.

You need to manage all those event types.

You need to write giant switch or if-then-else statements.

When debugging, event code will be executed at a different time from the actual event, making debugging difficult.

Your system does not work in the following cases:

1) if a parent widget wants to handle events from grandchildren.
2) if there is no parent widget.
3) if the children want to handle events of their parent.
4) if you want a subclass of a widget to manage the event raised by a base class.
5) if you want to invoke other code after the event.

Many people here say the event queue is the simplest option, but I say that it is not. Let's write some C example code to support our arguments.

Please show me an example where events in the event queue is simpler code than callbacks.

Here is an example of mine with a textbox that uses a callback to filter inserted text:

Please show me how to do the above with events.

And also show me one thing that cannot be done with callbacks just as easily as with events.

A function takes an allegro event and a widget and sends messages to the widget or its children, depending on the event type.

No widgets should ever handle events from any other widgets, they're just dumb views. All GUI event handling should be outside your views in controller code.
Widgets handle pure input and timer events.

There are some things I don't count in this. I don't know how to name it, the view internal behavior. Like, a text box does change itself on user input without a controller, a button gets pressed, a slider moves etc... It would be a real pain if the GUI user would have to make his own code for all this, that would defeat the purpose of even making a GUI library.

There's also the layout system, where containers and their children interact to handle automatic resizing and positioning. This is not handled through events or callbacks at all. Its a regular system of function calls up and down the widget hierarchy.

The only time widgets handle events from other widgets is if it's a composite widget. But then those events aren't even supposed to reach outside the GUI system, they're internal to a single composite widget.

EDIT:
If you put your widgets in a std container.

if("moved" == event.type && std::find(sliders.begin(), sliders.end(), event.source) != sliders.end())
{
   //Controll code
}

You could use two queues. This would brake the cicle.

hardware/system interface -> GUI-queue -> GUI -> game-queue -> game

The gui chatches the user input and either consumes it, or push it into the game queue. The only event source of the game queue is the GUI. I think the system does the same. If you resize a window it's done with the mouse. But you get an resize-event.

This way you could even run the gui in it's own thread.

Of course you don't put all the event handling in main. You make controllers that handle specific tasks.

while()
{
   ALLEGRO_EVENT event;
   while (al_get_next_event(event_queue, &event))
   {
      root->Handle_event(event);
   }
   for(Controllers::iterator i = controllers.begin(); i != controllers.end())
   {
      (*i)->Update();
   }
   root->Render();
}

Main() variables and global variables are the same, when it comes to using an event queue: all the code will be in the main loop, which has access to all the main() variables or the global variables. So, one might put the main() variables as globals.

So all of your users that prefer clean local code have to create events on their own. Thanks a lot.

Once again, here are the choices that you are giving your users :
A) Write arbitrary structs and functions to use in a callback
B) Use lots of global variables
C) Recreate events on their own

These are not nice choices to have to make for a user. Here are the choices you give your users when you use events :
A) Write clean local code
B) Use a callback function if they wish to, not because they have to
C) Use global or local variables as they wish, and not be forced to use globals just to work cleanly with your library.

These are much better choices to provide to your users. They can respond in whatever way works best for them, and they are not limited by callbacks.

You're kidding right? You use local variables because they are only supposed to last as long as the function that uses them. You use global variables because they outlive function calls. Don't use global variables just because they have global access. Say my gui handling wasn't done in main, but in a separate callable function, like for opening a dialog. Why should all the widgets in that dialog outlive the function they were designed for? It's a waste of memory, and bad practice. Besides all that, you can use variables of any scope when working with my library, but your library forces the use of global variables.

In some cases it makes sense to break up functions, but with widget messages your code is separated by if clauses. They're just as readable and just as modular as separate function calls, but you don't need to look somewhere else to find out what they are doing.

Go back to the example I just gave about using a function to bring up a dialog. The variables used by that function should not outlive it.

• You don't need a callback to have a context menu. Just make the widget own the context menu and respond to messages from the context menu. The user doesn't need to be involved in handling messages from the context menu at all, because the widget deals with them.

• A list widget doesn't need a callback to get list values. The user sets the values on the list whenever they feel it is appropriate.

• A widget that owns a scrollbar doesn't need a callback. It simply handles the messages that the scrollbar sends to it using QueueUserMessage. In a way, QueueUserMessage is the callback.

So the only example you can give me where a callback is necessary is with a textbox where the user wants to have a custom parser. That's fine, but it still doesn't prove that only callbacks should be used to handle messages/events from widgets.

You don't need to manage an event type at all. If a widget no longer exists, it will no longer send messages and the message check will simply return false and not be executed.

So what are the typical problems with using widget messages/events then? Nothing you've said about how it causes problems for you has ever caused any problems for me.

If you use widget messages then I would have 400 if statements, you on the other hand would have 400 functions and either 400 structs or all global variables. I would know exactly where to look when important actions occur, you on the other hand have to check which callback you set for which widget and then find that function across one or many different source files.

Currently, for the GUI test program, the source file is 700 lines long, of which there are 310 lines to declare widgets and 118 lines to deal with widget messages. I still know exactly where everything is, and modifying it is still not a problem. This is real life, functions take more than 40 lines.

My gui doesn't currently have any layout management, for now that is up to the user. It's very difficult for a function to know how you want to arrange your widgets unless you use some kind of system like HTML. I will have separator widgets that manage two widgets sharing the same space that divides the space between them though.

I don't really know what you're talking about here. Top level widgets are WidgetHandlers and they store the messages the widgets queue. After that, do whatever you want to with them.

In my GUI this is handled by a Shutdown function. If a child widget needs to cancel some operation during Shutdown then it will. It still doesn't require a callback. Generally, it's the responsibility of the parent to tell the child what to do, not the other way around.