The makefile was kindly donated by Bamcaig. Thank you Bamcaig. I am using Visual Studio on Windows, and I don't indent to spent any time with makefiles any time soon. I suggest you grab an IDE and just put the files to it, or, if you wish, make up the appropriate makefile and I will include it the project.

Quote:

stricmp wasn't found on my Ubuntu

Isn't stricmp a POSIX function in header string.h? why is it absent in your system?

Quote:

Why a separate event hierarchy? The whole point of having an Allegro GUI is that it doesn't add layers of interface bloat, in my opinion

What do you mean? widgets receive messages, not events. Messages have different data than Allegro events, and there are more messages than events.

For example, when you receive a mouse message, you get the mouse coordinates both relative to widget and to the screen, something Allegro doesn't offer.

Another example: when you receive drag and drop messages, you get the data source widget.

Another example: Allegro mouse moves are translated to mouse enter/move/leave events for widgets.

Quote:

This is especially evident with the timer thing... why can't you use your game timer for the GUI as well; why does the GUI need a timer of its own?

Because widgets may have embedded animations in them.

For example, a text widget will have a blinking cursor.

Another example: A list widget will scroll as long as the user holds the mouse button down outside of the widget.

Widgets will use the timer API to automatically manage timer events without the user having to do anything.

Quote:

Get a real game loop, please

You don't have to do anything special for the gui. You just pass the allegro events to it.

Quote:

It doesn't draw anything except the messages for me

Nothing is drawn most probably because the skin is not found.

What's your working directory? you have to set it to where the makefile directory is. The skin is to be found in the folder test/test-skin.

EDIT:

I replaced stricmp with strcmp. Unfortunately, stricmp is not a POSIX function.

Isn't stricmp a POSIX function in header string.h? why is it absent in your system?

It's not POSIX. strcasecmp might be though. Either way, there is something to be said for using Allegro's UTF-8 string routines for something like this.

Quote:

What do you mean? widgets receive messages, not events. Messages have different data than Allegro events, and there are more messages than events.

I don't know exactly what you're doing (haven't looked at the code), but the way I would make a GUI interact with Allegro's event system is to have it available as an event source, as well as providing a function that lets me pass Allegro events to the GUI handling function from the main loop. Is that what you do?

I set up a dual mode, one where internal messages are sent directly via callback messages (such that the widget can ignore or cancel the event) and a secondary userland version using the Allegro events.

That is, the internal non-Allegro "events" are things that are meant to affect the behavior or implementation of the widget. The external "something happened" event use Allegro events.

Strictly speaking, as long as there's some way to know that button Foo was clicked, Allegro events are not required. I added support simply because Allegro is my only target for the GUI and it seemed like the most natural way to do it.

So to me, the use case is simply "User processes events via the native Allegro event system", which is hardly helpful as an argument because it's circular.

I added support simply because Allegro is my only target for the GUI and it seemed like the most natural way to do it.

So to me, the use case is simply "User processes events via the native Allegro event system", which is hardly helpful as an argument because it's circular.

This.I process all input from a loop that listens to events. I would expect any GUI I use to fit into that design.Whether you agree and follow that is your own business, but it is what I personally would expect and want.

Hmm, in my gui I feed the gui with allegro events but I have made my own event system for events from the widgets. Perhaps I should add to my todo list to make it possible to get gui events into an allegro queue.

That means that if I want to put "Niño" as a name of my window I'm not going to be able?

You library seems really good, but no supporting UTF-8 is an error... there is people around the world using Allegro, apart from the USA most of the from the EU.

The UTF-8 API of Allegro is nice but I think the harder part wasn't developed... Exist al_ustr_append to append a simple charter or a string of charter to the end of another string. But should also exist something like al_ustr_erase to erase the last charter from the string.

This because UTF-8 uses 1 to 4 bytes to save info... so depending of the letter you want to erase you are gonna have to delete 1,2,3 or 4 bytes... so you have to do comparisons and blablabla... Someone correct me if I'm wrong because that is what I'm doing.

Of course this might take you a while, so you can leave it to the end...

I process all input from a loop that listens to events. I would expect any GUI I use to fit into that design.

My library does exactly that: it reads events from an Allegro event queue and then dispatches them to widgets. Widget messages are not placed in the queue though, they are executed directly from the dispatch function. But the event loop is still there.

Do you have any use case for widget messages (not events) to be placed in a queue?

That means that if I want to put "Niño" as a name of my window I'm not going to be able?

Yes. The window name (actually, window id) is not for display purposes. It's for programming purposes only, i.e. skinning, debugging etc, and I think that sticking to English makes sense: it's the simplest solution that works. It only requires static C strings. Putting UTF-8 there will make it necessary to do memory management on those ids, which is unnecessary.

Quote:

but no supporting UTF-8 is an error...

All the widgets will have UTF-8 text. Actually, they will have an ALLEGRO_USTR, just like Matthew's lib.

I would however like to see the widgets queue messages for the user, such as a button widget queueing a button_pressed message, a slider queueing a value_changed message, and so on...

This way the user can trivially connect one widget's actions to another. Like opening or closing a window widget from a button press, or changing a color from a slider value change, so on...

If you don't do that, then the user is forced to poll every widget for it's state on every update to see what has changed just so they can make their gui interactive.

It's not as trivial as you mention. You have to manage notification ids per widget: for every new command or option you put in the program, you have to allocate a new notification id. And this has to be done manually by the programmer. This is something that I have experience on due to using MFC, and let me tell you that it is very difficult and time consuming.

Furthermore, I am not a fan of big switch statements. They are counter productive. It's simply bad code to have switch functions with many hundreds of lines of code.

I am fan of callbacks (signals and slots actually).

In my library, users will be able to write callbacks which connect the appropriate widget actions to anything they want, including other widget actions, of course.

It's just there are some troubles with MSVC in East Asian locales, the gory details of which were elucidated earlier on this forum.

Ok, I didn't know that static strings can contain UTF-8 encoded text.

I am using ASCII strings for widget ids. Does anyone think that ASCII strings are not enough for such a job? for me, handling ASCII strings for widget ids has the following advantages:

no need to do memory management. With statically allocated C strings, each widget can have a pointer to a statically allocated string.

no need for extra string documentation regarding ids (who frees the memory, if strings need to be copied etc).

less memory footprint. If widget ids are allocated on the heap, then even if widget ids are the same for each widget class, the same strings will be allocated over and over.

some compilers are able to merge the same strings that are in different translation units.

vastly simpler programming regarding the parsing of skin text data. In the current code, parsing of simple ASCII text is very fast. Computations of string pointers are done by simply adding the number of characters to a pointer. This is not possible with UTF-8 strings. This also results to increased parsing speed.

In my opinion, I think that ASCII text for skin files is the right choice.