The makefile was kindly donated by Bamcaig (thanks man!). I suppose he has Allegro 5.1?

Qt Has an underlying event system, which its Signals and Slots sit on top of. Often signals and slots are sent directly via a regular method call (at some point), but you can also queue them up, which are then sent via the event queue.

For a pure GUI app, signals and slots make the most sense IMO. But it can take some extra work to get a game to fit into it, if you don't just handle the main game stuff along side the gui.

That rather depends. For some widgets, I may not be interested and simply discard their events. I would probably wrap the entire thing up into a function as well.
It all depends on how customisable I want the dialog box to be.

Perhaps the best way to do it is to be able to register, or not, a widget as an event source.

I would go so far as to say that you need something like this in a callback situation. Type conversions aren't such a big deal, in a sense they're simply a consequence of using C rather than C++.
Note that even Allegro's event system (if you use the user event API) passes custom data around using void pointers.

Sorry for interrupt your deep conversation about programming...

But I want to know, I compiled an Allegro 5.1 Windows binaries, it seems that works fine... (they are attached, if someone want to test it), but I still getting:

$ make
gcc -shared -Wl,-soname,libalgui.so -o lib/libalgui.so.1 obj/algui_list.o obj/al
gui_rect.o obj/algui_tree.o obj/algui_widget.o `pkg-config --libs allegro-5.1 al
legro_font-5.1 allegro_image-5.1 allegro_primitives-5.1 allegro_ttf-5.1`
Package allegro-5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `allegro-5.1.pc'
to the PKG_CONFIG_PATH environment variable
etc...
etc...
etc...

What are those "allegro-5.1.pc" files?

EDIT: Binaries doesn't work, when I run my program using them, It ask me for freetype6.dll. I did something wrong when compiling allegro... FreeType should be static or something.

I agree, but..

None of the advantages you listed have anything to do with ASCII or not, except the last. Even that is dubious. If your important characters are all within the ASCII range -- in practice, yes -- a UTF-8 string looks just like an 8-bit extended ASCII string. Non-ASCII characters are just passed through.

Anyway, this is verging on off-topic.

I actually took a look at my source code again, and I see I also wrote this function:

void algui_observe(void *component, int event_type, bool (*proc)(void *, void *));

used like:

bool button_onclick(void *self, void *event)
{
  ALGUI_BUTTON *button = (ALGUI_BUTTON *) self;
  ALGUI_CLICK_EVENT *e = (ALGUI_CLICK_EVENT *) event;
  // ...
  return true;
}

algui_observe(button, ALGUI_CLICK_EVENT_ID, button_onclick);

The return code determines whether or not the event bubbles up to the parent. For example, you could observe the mouse click event on the root node of the GUI to process every click.

This step happens after the widget implementation has a chance to process events internally. That is, there's also an onclick entry in the button's vtable. It gets called when the button is clicked, which allows it to do something related to its implementation or behavior.

It can then choose to emit the event to the user, which can handle it by the above code.

I do also support processing events via an ALLEGRO_EVENT_QUEUE, but after reviewing my code and remembering past thoughts, I tend to agree with axilmar that it's not very useful (particularly as the project gets large).

Just because you can do something doesn't mean you should.

Like I said, using callbacks/signals and slots is more work than it's worth. Why spend the time binding data into a completely different scope just to alter it? Why?

Did you even read my post?

What's simpler than this?

if (wmsg == WidgetMsg(&button1 , TOPIC_BUTTON , BUTTON_CLICKED)) {
   do_anything_here();
}

Give me an example of how using signals and slots or callbacks is simpler than what I just showed you.

At least we agree on this.

This is one of the few times that an immediate response is necessary and should bypass a message system. However, the widget could be designed to validate the data itself as well.

Cheese!! I want it! I want it!

I can't manage to install the library!

Can I compile the library without using pkg-config?

I downloaded the GTK+ binaries so now I have pkg-config but still don't working...

I don't know how makefile works

By ditching the Makefile I meant deleting it from your system with extreme prejudice.

Yes.. Instead of trying to fetch GTK to get pkg-config, you could have just grabbed pkg-config, or edited out the pkg-config bits and replaced then with the right -lblah strings.

Or manually compiled the code at the command line.

Edgar, why did you go to all that trouble? you could have simply written this:

button->click += slot(bind(my_function, special_int, special_double, special_bool, ref(special_object)));

Signals and slots are a lot more simpler and better than handling events in a queue:

• no need to manage event ids.

• no need to write huge switch or if-then-else statements.

• no need to have two types of callbacks (immediate callbacks and events from the event queue).

• signals and slots allow for putting together the initialization of an object and its signals connections; with events in a queue, this binding is far away from the place objects are initialized.

• signals and slots are better for the model-view-controller pattern: objects can be instantiated at one place and then passed to views, and those views can monitor the model by adding signals to them; signals and slots is a more object-oriented solution.

• signals and slots work independently of the main event loop: objects can have signals and slots in other threads that don't have an event loop.

• less memory footprint: with events, you need to constantly allocate and free memory for each event structure, fragmenting memory; with signals, you do the allocation once (for the slot) and then reuse the same slot.

• calling callbacks immediately leads to easier debugging; with events in a queue, it is a lot more complex: at the time the event is handled, the state that produced the event might have change, leading to confusion.

• signals and slots are better for time-sensitive loops because slots are executed immediately, unlike events which will be executed whenever their turn comes.

• signals and slots are better for debugging because the slot execution order does not change, unlike events which may come in any order.

• signals and slots can be created at run-time by reading a configuration file, unlike events, because event handling code doesn't have a name, whereas slots can have a name (the name of the function or method that is bound).

• signals and slots can be created at compile-time from a configuration file, from a GUI IDE creator, like Qt Creator does. No such luck with events.

• C++0x will have lambda functions, which will make the bind function redundant. And lambda functions can access the local state. And lambda functions can be slots, unlike events, so there is no need to modify existing code to accommodate lambda functions.

• when using signals and slots, objects in slots can be bound using weak pointers; when the objects are deleted, the slots are invalidated and removed from the signals they belong, and thus only the necessary signals remain to run. This can't be done with events: the event code will be there, even if it will not be executed since the object it references is no longer alive.

• signals and slots is a lot more flexible system: slots can be added to signals from any place in a program; with events, all the necessary event handling code must be in the same place. You can't add new event handling code in a running system.

• signals and slots works better with plugins (i.e. DLLs): just pass the signal to the plugin object, which will add a slot to invoke the necessary plugin function. With events, you have to imitate slots (i.e. registering callbacks).

• signals and slots can be chained: signals can be slots. Can't do this with events.

• signals can be used as functions in functional programming style. Can't do this with events.

• signals can be bound to arguments, producing function objects with less parameters. This leads to better code reuse than events.

• signals are better documented than events: signals are visible as object members, and can be documented accordingly. Events are more difficult to document, since there is an event id and event struct declared separately.

• signals are much easier to declare than events: signals are declared as one liners (signal<int, double, string>) vs events which are declared with an event type id and associated struct.

• slots can be generic function objects, for more code reuse; generic function objects can be used in many places besides slots: callbacks, lambda functions, message queues, etc.

• signals can be emitted in one thread, and slots can be executed in another thread, using the same expression (signal += slot). You can do this with events, but you need to invoke different functions (usually it's put-event vs post-event).

• signals and slots don't need an event queue: you can take code that uses signals and slots from the main thread and put it in another thread without changing anything. No such luck with events.

As was pointed out, the Makefile was contributed by me. If you don't like the Makefile there then fix it or replace it with something better. That's the best that I know how to do right now, but it's better than plain bash scripts or manually typing commands every time.

As for the Allegro 5.1 usage, I honestly don't know anything about it... All I know is that at some point somebody (probably in IRC) pointed out 5.1 (or maybe I just saw the branch in Subversion) and I started using it. I have no objections to updating the Makefile to use 5.0 (I'd do it now, but I'm in Windows still ripping CDs).

The Makefile was written in Linux (Fedora 13). It's not very robust and not platform-independent. The good news is that it's open source so go ahead and fix it and contribute your fixes. Or if you don't care about a build system and just want to build it, compile it manually; on the command-line or using your favorite IDE. The pkg-config system is used in Linux to fill in the link libraries in a pretty way. Allegro 4 did something similar with allegro-config, but again, I think that was Linux only. Have you considered switching to Linux?