Not really. GEM + TOS on the AtariST came to 192KiB. The only extra bits needed are the hierarchy tree (each object has parent, sibling and child pointers) and the dirty rectangle system (which subdivides the whole screen into paint areas).

Neither of these are particularly difficult to implement. If I hadn't tried so hard to avoid making a whole new incompatible GUI, I would have implemented these by now . I regret my decision to persevere so long with Allegro 4 GUI which has so many flaws for complex programs.

There has to be a dividing line between providing every single piece of code that any game may ever need and providing just the bits that every game will definitely need. Allegro traditionally steers a pragmatic course between the two. New-fangled Allegro 5 makes things even better by pushing the core library back to the edge of the spectrum and supplying add-ons that make its exact positioning optional.

I did at one stage have a decent enough clone of most of the QuickDraw drawing operations, but including arbitrary clip areas (essentially software-based stencilling) basically means rejecting most of Allegro's built-in code so I wouldn't advocate it as either something that should be built into the library or should be considered an officially supported add-on.

But there are a million ways to implement GUI functionality that are entirely different to Allegro's model, and another part of Allegro has always been not forcing design decisions on the end user. That's why it is still a C based library with relatively low level operations.

For those two reasons, I respectfully disagree that DIALOG or a DIALOG variant should be a central part of the library.

However, as I said before, I'm not one of the Allegro developers, I'm just expressing an opinion. My judgments about the design goals for Allegro both now and in the past are my own and may be incorrect.

I use C.
As long as I do that (and as long as I make games with Allegro, which is admittedly somewhat intermittent at the moment and likely to stay that way) I'll have a need for the equivalent of Allegro's GUI. If I can be bothered to clean it up enough to release it as an addon, I will. Someone can always ask for it if they want it.

Actually, why would you be afraid of losing it? It's not actually very hard to take Allegro 4's code, modify it, and add it to your own project.

Glad to be of service.
Now all I need is a pretty girl on the forums who uses Ace as her avatar.

Part of the reason I don't like A4's gui is the inflexibility of the DIALOG struct and global gui functions that rely on them. They're nice to a certain degree but tend to force the user into using global data and scattered code. At least in C++ this can be more easily avoided, which is one reason to let the gui be created as an add on. Of course, it would always be nice if it was an officially supported add on.

I usually program my own buttons and text input because I don't like allegro's way of doing things. It isn't that hard.

Brainstorming sessions do not work. Whoever finishes a C GUI addon first, will be the one who decides what is good and what is not, and how to do things.

I agree. Screening after the addon is done, not before. I for one think A4's GUI design and operation is near perfect as is, and any deviation from that proven formula is a very, very hard sell for me personally.

I hardly think making a good C GUI would be a waste of time whether it is accepted or not, but point taken.

In that case, here's what a perfect gui would look like for me:

Alternatively, for people who don't like the state based approach, the main loop could look like this:

A library can't have everything everyone desires. Furthermore, that's what libraries are for. If someone can't deal with linking to one more library, then they shouldn't be programming.

A proper GUI is a tremendous job, much larger than Allegro. You have to cater about how the screen is redrawn, if the redraw method is appropriate for games, about keystrokes, about data events (remember the recent discussion with Reynaldo about how to easily change data and notify the GUI at the same time).

You have to present decent default graphics, but also allow the user to change the style.

You have to cater for the input focus, and for data validation.

You have to have layout management.

So, under this light, it's better to have the GUI as an add-on.

Regarding the current GUI, it's a mess. It's appalling, both presentation-wise and coding-wise. It sucks big time. I don't object to a C gui only (C++ is better suited for guis though, but apparently many Allegro coders like to torture themselves :-)), but it has to be better than the current one.

The appropriate way to compile things is to put the common library paths into environment variables or tool settings and pass the variables to the make tool.

Personally, I am using Visual Studio, and I never had any problem with libraries and paths. When I download a library, I put the paths in the compiler settings. You can do that with any modern IDE.

And what is core gui functionality?

For me, layout management and data events are 'core' to the gui.

Well that's 'core' to a GUI, except the drawing stuff

The A4 gui isn't the best piece of software. But it a good example for a small and basic set of structuring support. There are better solutions but the code is easy and small. So the components you are talking about are core, but aren't to big for including it as shown by the A4 gui. Things get even smaller for A5, because there will be an event queue or someting similar. So there is no need for an extra event system.

Throwing out the d_proc stuff would reduce size dramatically. It's the game programmers choice how his game elements look like and react to events. I say game elements here, because the structuring part is not gui specific. You can use it for everything.

As long as you act as an developer on the code, the way you described is OK. But when shipping your code, you need to use a build system. And these build systems try to locate the needed libraries(./configure, cmake ., etc.). But when there is no support by the used lib for the build system you are using, you has to set up things manually, which is in case of the many platforms available no trivial task.

In allegro 4.2 there is a function called file_select_ex where you can look for files to save and load on the hard disk.

Instead of using a gui in allegro to do this is it possible to add the operating system's default save/open dialog? Or do all of the operating systems allegro is meant to work on not have one?

http://www.winprog.org/tutorial/app_two.html

I am looking at this but I don't know how to get the owner's window.

ofn.hwndOwner = hwnd;

It seems to work with that part commented out but does it need it set to avoid memory leaks?