No. I'm simply suggesting that you design with these limitations in mind if you want to use allegro. Anything else but these two other options would be stupid:
- Add the feature and submit the changes
- Don't use allegro.

But it's really, really stupid to know about a limitation, ignore it and then start whining. That makes no sense at all.
As far as I'm concerned, there's just one problem with the GUI for example: The fact that widgets use:

while (gui_mouse_b()) {
}

because that's really a bad thing.
The remaining problems can be dealt with with some effort.

Oh... and I did the search for you:

Oh.. and one post above that post from Bob you realize for the first time that there's a GDI driver for Allegro...

I understand why the looping is a bad thing and I couldn't agree more, but do you have an example of a way around this? Besides that GUI's aren't really made for games, or to be drawn on top of a game, I don't really see the windows desktop displaying a full screen game while widgets are drawn on top... that's the whole concept of windows, make the game inside a window, that way the GUI has control over the game window. It's not that hard to put a game in a window anyway, my GUI pretty much does that with the spectrum proc, you could have anything inside that window.. even pong. I think that would be kinda nice to do one day is make a game completely inside a dialog box that's resizable and has menus etc. Then you could play the game and switch between windows, etc. like any other windowed environment that's currently out.

Yeah... Allegro uses DX3. didn't you know? It may require a later set of headers to compile, but the interface it uses is pure DX3 IIRC.

IIRC, you can't ask to resize a DGA buffer either. Or an FBCon, or Svgalib... or a plain Allegro memory bitmap. Weird no?

Stop complaining, add this feature, oh master Korval..

I'm still of the opinion that the Allegro GUI can be fixed by making it non-modal (optionally, for backwards compatability) and with object-hierarchy and a DRS levered in somehow.

The fewer changes that are made to the existing GUI standard, the less work is needed to learn it and adapt existing code.

MasKing and DeGUI are already a good start at a C++ wrapper. dlg is a good start at a dialog editor. I really don't see any great benefits to starting from scratch.

When I get a server sorted. I will post my docs and invite further criticisms and contributions of examples etc.

It's hard to design a GUI system from the top-down because you can't see any problems until you actually use it for real. I say go ahead and just write a few programs, do whatever you need to do to get it working, then have a look at the ugly hacks you needed and then consider how to smooth things out or hide the hacks inside the GUI behind a regular API.

I still can use a while(mouse_b & 1) loop in my GUI by broadcasting MSG_IDLE to the entire dialog while within it, this seems to work for me, it's blocking, but not stopping any animations.

My gui lib doesn't need the loop: the gui engine itself controls mouse clicks, and only sends a mouse click msg if the mouse is pushed and released under the same object. Also, while the mouse button is down, only the object that got the mouse_down event gets the mouse events (so no event is sent to other object if you move the mouse over it).

I don't have a dummy proc... instead I overwritten the do_dialog procedure to call a function at intervals that takes care of updating the screen contents.

Something along these lines:

while(player = update_player()){
     update_screen(buffer);
}

as for tools, I might throw in, allegro mixes well with GTK. portable and everything.

Spell, I think you may be correct there, that's why I actually have my update_screen() procedure in two places, one inside the dialog_proc(), the other after update_player(). When a button is pressed, the update fps goes down... since of course i'm determining my fps inside update_screen(). The code is in both places so either event won't stall the system completely, it's crude but works anyway.

[edit]
yeah pretty much the way it is, if I remove the call in the MSG_IDLE segment of my dialog_proc() it will freeze if I push a button, it also makes for some pretty interesting effects when dragging teh dialog box... it seems to pause, then redraw in the new spot, but updates the background very slowly. Removing the update_screen() call after update_player() however does very little, it just reduces the total fps, so I'm pretty sure that call is uneccessary. So yep.. pretty much you have to have a call to update_screen in at least one proc, or a proc that does it separately in order for DRS to work.
[/edit]