Ok, the old thread grew to long, and was turning into somthing getting in the flame direcion.
That's one problem with longer discussions...

Maybe Korval could list the planned features for the gui lib here? Like on the back of a software box? This wil be better start, since the design of that lib is fixed already anyway. So starting with a list of features + some implementation details might be better.
So you can get some feedback, and I don't get tempted to come with totally new concepts

Well, here's my design so far. This is just the high-level overview. Not only that, it is somewhat incomplete, especially considering that it doesn't include anything about the control-data paradigm.

Message Passing:

There will be a message-handling facility. All objects that handle messages are derived from Class MsgHandler. A MsgHandler has a non-virtual function that calls a virtual one. The non-virtual function actually receives the message from the sender. The virtual one is where user-specific handling occurs.

MsgHandlers are in a tree known as the Message Path. Some object resides at the root of the tree. When a message is sent to a MsgHandler, if the virtual function chooses not to process the message, it is passed to the parent in the tree. It continues until it reaches the root. Any non-input messages that reach the root cause an error.
There are two ways to pass a message. One way is to simply post a message to the message queue. This message will be processed when the main GUI’s ProcessMessages function is called. The other way is to send the message directly. The SendMessage function does not return until message processing has finished. Care should be taken with SendMessage; use it only when it is absolutely necessary, and never outside of a message processing function.

Sent messages have a source and a destination MsgHandler. A Message consists of a 32-bit int defining the name of the message, 2 32-bit ints for parameters (possibly pointers), and a pointer to the MsgHandler that called it. Input messages will have a NULL source (either that, or they are generated by the root MsgHandler).

User-Defined Message Handlers:

The user can create a class derived directly from MsgHandler that can be added to the Message Path. These classes can be used to define particular modes of the GUI. For example, when a user presses the GoToInventory menu option, this option causes the basic Handler to remove, or delete, its controls and create an InventoryHandler. The InventoryHandler can create controls that display the inventory, as well as handling messages that change the contents of the inventory. This is one method of laying out this code; the GUI Library provides for others. However, having these Handlers is usually useful for a particular section of the GUI; that way, controls can be as generic as possible.

Windows:

The core windowing system will be defined as follows. The base Window class is derived from MsgHandler, as all Windows need to be message handlers. A Window provides for an interface to the following:

· Position (absolute and parent-relative) & size (client and full-window. See below).

· Z-order

· Parent access

· Visibility

· Rendering

· Scrolling (the client area of any window is, by default, scrollable. Users should be aware of this). Children of a window scroll with the client area. See CScrollView.

· Child access (container stuff). Child Windows are drawn inside the client area of a Window.

· Mouse capturing.

· Input Focus.

The user should call the Render function for the top-level GUI class that serves as the parent for all Windows. If this class was created with the understanding that it would redraw only when necessary, then it will watch for a specific redrawing message that only it is supposed to handle. When that message is sent by a control, it will cause the redrawing of the entire GUI.

A Window has a “client” area and a “window” area. The client area is the section of the Window that the user draws in most of the time. The window area is the full-size of the window. The GUILook (see below) is usually responsible for drawing the actual non-client areas. Indeed, the GUILook typically defines what the extent of the non-client areas are.

Scrolling behavior should be introduced as unobtrusively as possible. That is, if the programmer making a Window doesn’t want it to use scrolling, it should not have to pretend that it is scrolling. Hopefully, Windows that don’t want to scroll shouldn’t have to do anything special; the scrolling ability should be as transparent as possible.

The Top-Level Window:

The top-level window of the GUI is special. It is derived from the Window class, but it has additional functionality. It provides the user’s interface into sending/receiving messages to and from the windows in the GUI. Indeed, it provides the user interface for all functionality that affects the GUI as a whole. The top-level window defines the GUI. In particular, the top-level window does:

· Interface for the user providing input
· <More to be added later>

Look:

The “Look” of a GUI comes from the term “Look-and-Feel”. In this case, however, allowing the user to globally control the actual feel, that is, the interface, to various controls is beyond the scope of this design. Writing a good set of control interfaces should handle that.

Therefore, the “Look” refers to how buttons, backgrounds, fonts, etc looks to the user. This is commonly referred to as GUI “skinning”, though this is a misleading term. In this case, the GUILook class provides functions for drawing very basic GUI elements, as well as storing important GUI objects.

· Standard colors for foreground, background, the colors used for the sides of 3D-looking controls, etc.

· Drawing a background.

· Drawing a button (in various states: raised, lowered, neither, disabled, etc), given either text or graphics.

· Drawing a check-box (in various states: checked, unchecked, neither, selected, disabled, etc). Possibly given text or graphics.

· Drawing a radio button (in various states: on, off, inbetween, selected, disabled, etc). Possibly given text or graphics.

· Storing various fonts (small, medium, large, etc). All GUILook functions that draw text will use a particular one of these.

· Drawing horizontal and vertical Scroll bars.

o Window should try to automatically handle this as much as possible.

· Drawing a standard window (includes the background). If you want to have a title bar, an outlined border, or something that most windows (but not all) have, this is the function to use.

o Using the standard window drawing requires an added computation to determine the “client” area of a window. The GUILook provides this functionality, and the Window class should have a hook that makes this totally transparent to the user of the Window (if at all possible).

o Draws enabled or disabled.

· Top-level window drawing. If the top-level window looks different from the rest, this is the function to specify this.

o Also uses the facility to determine the “client” area of the window.

Not all window rendering requires this class. However, a window should leverage these renderables as much as possible, so that the look of the GUI can be easily changed with a change to this class.

Perhaps, if the efficiency hit isn’t too bad, an extensible mechanism can be created to add new drawing types to a GUILook-derived class.

Regarding your platform independent features:
Quartz extreme

While this is no tech document, I thought you might be interested in this.

Maybe this GUI can also be used to make allegro tools, which there are not enough, methings.

i dont think allegro was made to make tools with, it a game lib, not a tool lib::)

Games, especially games of any real size, need tools. You need tilemap editors, sprite animation editors, etc. These are things you have to have in order to effectively build a game.

Granted, the GUI library doesn't have the foundation of a Win32, Motif or something of that nature, but it does have one advantage: it works in Allegro. A tool that actually works in the rendering environment of your game makes it that much easier to write a WYSIWYG tilemap editor and so forth.

One problem I know I've had with Allegro is that it couldn't be bound to an actual Win32 window that featured resizing and so forth. The solution would be to have a GUI that works in Allegro that is fully-featured enough to actually write decent tools.

I belive it says in the manual that the allegro gui was only created so that it could make allegro tools (primarily grabber).
That's the problem with it. It wasn't designed for use in games.

Considering what's there, it wasn't well designed for tools either.

It can be, but that is more work and destroys the cross-platform nature of your code.

It is very incomplete, but the basic structure is usable. The biggest drawback I have found is that objects all have the whole dialog as their only parent, which makes things harder work than they need to be.

Many people have attempted to make a better GUI, but they have all failed to gain a sizable user base. This is why I am making tools which use the allegro GUI as-is with extensions which don't break the existing API. When I am finally forced to break the API (in order to let objects have other parents) it will be minor changes.

I think the pragmatic way to design a GUI is just to write a few games and attempt to reuse as much code between them as possible.

Regardless of how much (or how little) I care about making cross-platform games, there is no problem with making platform-specific tools. The only time you care about whether or not your tilemap editor is cross-platform is if you expect to give it to someone else to use. Considering that this is a relatively rare thing indeed, there is simply little need for cross-platform tools. Indeed, many tools can benifit greatly from platform-specific code.

Use SYSTEM_NONE + memory bitmaps and blit the result to your own window. In the resize code, make sure to create a new memory bitmap and blit the old one to the new one before you destroy it.

Unfortunately, this relies on doing GDI blits, which are unacceptably slow. Even on my older Althon 650, you could see the GDI in mid-screen blit.

I thought we're talking tools here? I doesn't really matter for me if I see some shearing in my map editor
Oh... and since you don't have much choice... destroying / recreating the primary surface isn't the fastest thing either.

How often do you resize the window? You will probably force a redraw of every other window on the screen anyway.

When you do resize, remember to snap the horizontal size to a multiple of 8, to work nicely with Bob's colour convertors in all combinations of colour depth.

I really must try this sometime, as all my GUI demos have a resize function already. I only use it for setting the initial size at the moment.

Works great for me

True, tools don't need to run as fast as the game. But they do need to run at a reasonable speed.

The other problem with your suggestion is that the engine (and the point of putting tools in Allegro at all is to be able to have WYSIWIG results) must be designed to work within this environment. Sure, if your rendering code uses main memory buffering to draw with, then your method works just fine. However, if you use multi-buffered page-flipping, and you expect to have the vast majority of your BITMAP assets sitting in video memory, you've got problems when you take that engine into a main memory buffered environment. To make the page-flipping engine work, it has to be able to load its assets into main memory if you set some flag. And, of course, if you never intended your engine to work in such a fashion, why would you have such a flag built into your engine?

What's your problem?

What engine are you talking about? Why should I add a page flipping flag into an editor not using page flipping?
What engine are you talking about in the first place? If I create a create a palette from an image there's no need for an engine. If I create a sound editor, there's no need for an engine.

And just for the record: If I would create such a system, it would be able to handle double buffering and pageflipping. It would be able to use both video and normal memory.

Why do you always construct stupic examples just to show how stupid they are?

I mean, why are you creating an engine which can render BSP trees, if all you need is to exchange the red and green channel of a 32 bit bitmap? That makes no sense. You shouldn't do that.

Try removing the blindfold, take a deep breath and try to be a bit more open minded.

Or start creating your engine / gui / next game / flux compensator / time machine or fnord.

I really don't get it why you want to create problems instead of solving them.

No, the idea is that you can use a powerful engine to render gfx with.

Are all your tools low-level things like palatte editors or waveform editors? Or do you actually intend to have some real tools like a tilemap editor, sprite animation editor, or a GUI layout editor (indeed, I would consider a palatte editor to be part of the tilemap/sprite editor, not a fully separate tool. At the very least, it's a .dll rather than a standalone .exe)? Things that rely on how certain, engine-specific, underlying code actually works. Because they rely on some core engine, in order to get WYSIWYG results, you have no choice but to use your exact engine to draw them in your tool.

Of course, if your engine doesn't draw using main memory, your memory-to-GDI blitting scheme doesn't work.

If I'm making a music editor for use with a game that uses DUMB to render its sound, doesn't it make sense for the music editor to, also, use DUMB to render the sound? This not only makes sense, but is immediately obvious to anyone who thinks about the problem for a few seconds.

Good for you. That doesn't actually solve the problem, of course (the problem being an engine that doesn't conform to this concept), but it's nice to know.

It is hardly unreasonable to make a choice early on in development for a particular rendering system based on performance. And, not only that, this is the correct choice, based on performance. The fact is that video-to-video blits are, at worst, no slower than memory-to-memory, and are likely to be quite a bit faster. As such, it is hardly unreasonable to think that choosing a pure multi-buffered page-flipping approach from the beginning is a bad choice.

That's like saying choosing OpenGL for your 3D renderer is a bad choice, because it doesn't let you have good direct access to textures. If your game doesn't call for direct access to textures, it isn't even a consideration.

Lastly, there is no real reason for Allegro to have this significant limitation built into it. I can understand having some drivers simply not support "playing fair" in a window. But to not even have the option for certain drivers to allow for window resizing and so forth (especially message passing)... why not? I've seen DirectX windows that work just fine with resizing. Why is it that Allegro doesn't?

I could just as easily ask why it is you never comprehend what I'm talking about. And this isn't even particularly difficult to wrap your head around.

I am, quite obviously if you weren't already predisposed to disagree with whatever I say, refering to tools of some significance. Obviously a tool that swaps color channels doesn't apply; I never intended it to. Such a tool doesn't even need a C program; a Perl or VB script can do that just fine (well, maybe not VB...). But for a real tool, a tool that creates data for a significant system of your game, yes, you do need to have your game's corresponding system being used as part of the tool.

Because your solution (let's all build our engines to support both rendering methods, even though we have no desire to ever use the main-memory one) is hardly a reasonable solution. Rather than force everyone to adopt a particular paradigm that doesn't really do much for the ultimate purpose of their code, why not simply change the library and fix what's wrong with it?

If your engine doesn't support floating point variables, you'll have to use ints.

That explains why it needs video memory.

No, the engine does support this. Of course. Why shouldn't it? Do you have any reason not to support it? The engine does support it. Believe me.
While i'm not sure what engine we're talking about, and why you assume it doesn't support normal memory is a mystery to me, I'm pretty sure that almost every engine will support system memory. If it doesn't then it sucks, and shouldn't even be used to display the time left on a microwave.

ROFLMAO

Page flipping was slower then vid->vid blits on my old card (ati rage fury) and it's also slower on my new card (geforce4 ti).
Also, from the view of the program there's no difference between mem and vid bitmaps.
Page flipping / double buffering is just a function pointer which needs to be switched.

Search the forums. I've seen Bob's the answer two times I think.
You could also stop crying and add the feature

Because, quite honestly, you're talking garbage. You construct examples as you like and insist that these examples are the way it is.

I'm so glad you know what you're talking about.

Argh!
That's not my solution. The thread went like this: Somebody wanted resizeable windows for allegro to create tools. I told him that he can use SYSTEM_NONE. You started to blurb about page flipping engines and why night is darker as stones are tall.
From there we were discussing the hypotethical non-working enigine for a problem which hasn't even postulated.

Then you started to blurb about using engines not supporting video bitmaps as the only true way (while on the other hand you plan to build the Titanic of GUIs).

Ahm.. are we reading the same thread here?

Let's assume that I have this unflexible (and IMO pretty useless) engine which won't work w/o video memory. I'm not sure why it doesn't work without it, but let's just say it doesn't.
Let's assume I use allegro. What's your solution to the problem?

Ok, you could simply take the engine, change the 3 lines used to allocate the bitmaps and displaying the back buffer to support mem bitmaps... and no, you don't need to have 2 copies of the source tree then, no you don't need to maintain something more... and no it won't slow down the engine in any way.

Look, at the very least, you could pretend to be unbiased in your comments. Since I was responding to your comment that, "If I create a sound editor, there's no need for an engine," I was, obviously, not intending this analogy to deal with the issue of a graphics rendering system using video memory. It was intended to deal with your claim that you wouldn't want to put an engine into a tool at all.

Once again, your beliefs and (random and arbiturary) assertions do not actually solve the problem. At best, they define it away simply because you can't fathom that anyone would do something as insane as pick multibuffered page flipping as their only rendering method. Just because you think it sucks and that you, personally, would ignore the idea as absurd doesn't make it a sucky or absurd idea.

Such a deft parry of my thrust. I'll presume by your lack of argument that you accept it as fact.

I don't know about your Rage Fury (it may not have even had hardware accel), but I can guarentee that your GeForce 4 is not really slower in page flipping mode (especially since my Ti4200 can beat my Athlon 1900+ by at least an order of magnitude). Did you turn vsync off? Software doesn't have to wait for the vsync, but hardware flipping does. Are you using "request*" or the direct "show" or "scroll" functions? Since you're drawing to a video BITMAP, did you acquire it before doing all your drawing and then release it afterwards?

Yes, you could implement them in a similar fashion... if you're not interested in optimizing them. You see, how you go about making a memory-to-memory blitter more efficient is a very different thing from making the video-to-video one more efficient.

In the memory-to-memory case, you buy a lot simply by buffering. I could easily imagine a 640x480 tile engine that would store a 1280x960 block of the screen pre-blitted. Then, as the screen moves around, it could reblit the image. This does cause occasional jerks, but it is much more efficient than blitting each tile individually. Or, to smooth out the blockiness, maybe you carve the screen up into blocks of, say, 20x20 tiles that you pre-blit (as needed, of course). These are all valid optimizations for the memory-to-memory blitting case.

However, video-to-video blits don't need that. Indeed, it's a very bad idea to even try, as that 1280x960 map takes up precious video RAM. A key to optimization there is to leverage the vast speed of the blits themselves. Also, using the "request" to flip pages rather than the "show" can save you quite a bit too. Lastly, if you're going to have any fair performance comparison, you really need to turn off vsync; it unfairly penalizes the video case.

As you can see, switching from pure-video to a memory-based blitting scheme isn't just "a function pointer which needs to be switched." A rendering system that relys on the rapid blitting of a lot of little tiles is going to have some issues when you switch it over to memory-to-memory, especially on slower machines.

And, since I know you're simply going to reply, "But, isn't it just for tools? You don't need that performance in tools?" I'll go ahead and counter the actual thrust of your argument, too.

In order to make this switch work, you have to load all your BITMAPs into main memory, rather than video memory. At the very least, especially if you never intended for this to happen, this will require some new loading code. It's more than just calling "create_memory_bitmap" rather than the video one.

Next, you have to deal with the issue of actually doing the blit to a memory buffer, and then blitting that to the screen. It's hardly unreasonable to think that, somewhere in their code, is a bare call to "request_show", rather than them calling an easy-to-override function. After all, they never expected to ever need to change this code. Now, you have to refactor that call out into your code, and build a new version that, instead, blits the memory buffer to the screen.

Now, if they used scrolling, rather than "request_show", you've got a much larger issue (and they need to have their head examined, but it is still a not-too-unreasonable choice they could make). Since they used scrolling, they're probably blitting to some offset into the actual 'screen' BITMAP. Now, you'll have to find all the references to the screen and replace them with another BITMAP that you can substitute for either the screen or the memory buffer. Also, you'll have to change each Blit/DrawSprite command so that it only does the offsetting when necessary (unless you make your memory buffer the size of the screen BITMAP). Or, better yet, make the sub-BITMAPs (that they should have made themselves instead of passing around offsets) of the screen and pass those around as necessary, abstracting the scrolling into a "request_show" form.

And, of course, this working all depends on the hope that they aren't doing something (accidentally) that is technically a bug, but video memory doesn't mind, but main memory will crash on. Like blitting outside the actual BITMAP, for example. The screen, of course, can survive just fine on it if you have enough virtual screen around it. A memory BITMAP will either start trashing memory or cause some kind of GPF/SegFault. If they are doing something like this, you have to hunt it down.

Do-able? Certainly. Trivial? Hopefully, but (especially in the scolling case) you're doing some very error-prone things in the code. It could be as easy as a "3 line" change, but I wouldn't bet on it.

Porting from one type of system to another, even in something as simple as this, is never as simple as it looks. It all depends closely on the particular nature of the code.

Honestly, how many people using Allegro have the experience to write their code in a way that makes it an easy 3 line change? Some, yes. But most simply don't have the hands-on experience to know instinctively the "right" way to code. And that's what you're talking about dealing with here.

His answer does not satisfy me.

If you never note that a problem exists (and, apparently, noting the existence of a problem or limitation is tantramount to "crying" in your book), it will never get fixed. Nothing ever improved by accepting the status quo.

And, to be honest, if there were some actual documentation on writing an Allegro driver (preferably something along the lines of a step-by-step list of things you have to do), I would probably have started on one for GDI+, that would provide for resizing.

The thread went more like this:

1) I mentioned that Allegro didn't have the ability to live happily in a window not of its own creating.
2) You mentioned that I could always use GDI blitting to get around this.
3) Having already, not only realized this "solution", but also realized the limitations of it, I endevoured to explain why this is not an optimial solution to the problem.
4) Upon mentioning that you can't plug an arbiturary engine into the GDI blitter, you question both that fact and the need to have engines altogether.
5) I successfully convince you of the need for engines to be able to be used in tools (you didn't attempt to argue against it). However, your belief that a rendering engine should always be written to support main memory blitting prevents you from accepting the argument against putting an arbiturary engine in the GDI blitter.

Or, put more succinctly:
I say there is a problem with Allegro.
You propose a workaround.
I mention that the workaround only works if you're rendering a certain way.
You say that you should always be supporting that method.
I say, "Why?"
You say, "It's easy to."
Now, I'm saying, "Not as easy as you may think."
I'm guessing your response will be something like, "No, it's easy."

I didn't say that it was "the only true way". I pointed out that, if you want performance above all else, accelerated video-to-video is the way to go. This is not an opinion, nor is it a subject up for debate. It is, simply put, a true fact. Regardless of your beliefs, or how you may have misinterpreted some benchmarks you made in the past, accelerated video-to-video gives greater performance than memory-to-memory blits. Especially for larger tilemaps with more colordepth.

The fact that is is a problem is the point of this discussion. It ought not be a problem. And it wouldn't be a problem if Allegro were not limitted in this capacity.

As I mentioned before, this is quite untrue. Well, let me clarify that. Running it in main memory mode will incur a speed hit. Simply having the code around will incur some slight overhead, but nothing more than a few cycles that you'd probably be wasting waiting on a vsync anyway.

Once again you should take the complete discussion into account. We were talking abou tools. Then you started talking about engines. So I thought I could contine in this tradition and mention even more things with not direct connection to the actual point.

Exactly. I see we agree. Why would somebody want to do that?
Since we agree on that this is stupid, I think we also agree on that the engine can support both double buffering and page flipping? If so, the engine can also use normal ram -> the whole discussion about vid mem is pointless.

Yep. They would have never believed they need tools Oh come on, stop that.
Now you're starting the "they coded crap, because that's the only way to make a valid point" thing again.
Or let me put it another way: If they're stupid enough to do it the way you described, they deserve to be punished for that.

I never said mem->mem is fatster then vid->vid. He who can read has an advantage.
In other words: read again.

And your solution is? Try to provide solutions, not problems...

No it isn't. Read it again. Now, instead of creating a problem, try to see the solution...
you have two ways of rendering... and still... just one codebase.. and it doesn't get slower.. what could that mean?
Small Hint: There're at least two solutions for this amazing riddle

If only the tool runs in memory, the actual game will not be affected
And before you blurb: That's not a problem. The debug build of your engine will run slower as the release build as well. That doesn't mean that you never do debug builds.

I just want to make sure we all fully understand what you're arguing.

Allegro doesn't support a feature that it, by all rights, ought to. Instead of pushing for Allegro to be more feature complete, you're suggesting we all simply force ourselves to use the codepaths that can be used to work around (aka: hack) Allegro's deficiencies.

I just want to make sure that it is understood, outside of everything else said here, just how unreasonable that notion is. After all, you're talking about everyone using the library having to code around this bug. Wouldn't it make more sense to petition the Allegro developers to simply repair the deficiency? Just because you can hack your way around a problem doesn't excuse the existence of the problem itself.

Yes. I petition for Korval to fix the Allegro GUI.

It, indeed, is ugly (although gets the job done for the simple tasks) - and a nice one could be justified (assuming it wasn't horribly bloated.) The Allegro tools could use a good GUI. Custom tools could use a good GUI. Even games could use a good GUI.

http://www.members.cox.net/skeevewoo2/NASamp

What's wrong with NAS GUI and MASkinG. They are both skinnable and are both much nicer looking than the default allegro GUI. Though Mirans is still more complete and more advanced, if everything works out mine will be pure C. That way programmers can have it either way.

MASkinG is no good for serious work as I just recently found out. Well, it's sort of half good for tools but doesn't work well in games. I still have to work on it...

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...

No can do. I don't write pure-C code anymore, so it could never become truly part of Allegro.

Just because Bob said it doesn't make it true.

For example, I'm looking at a piece of MFC-based DDraw (IDirectDraw4) code right now that, while it does have to destroy it's back-buffer surface on resizing, it does not need to destroy it's other surfaces.

Now, granted, I'm no DDraw expert, so I could easily be misreading something. However, it certainly isn't destroying dozens of surfaces in its OnSize procedure. And it runs just fine. I can resize it, and it all just works fine.

Also, I would like to point out that, even if this deficiency in DDraw existed, that doesn't excuse not having the functionality if the user requests it. After all, Linux, *nix, and other OS's don't have these problems; only DirectDraw. As such, if you ask for an AUTODETECT_WINDOWED_TOOL, it simply won't be able to give you a DirectDraw surface.

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.

The widget in question could request a "mouse grab" and get all mouse events until the widget releases it.
Another option (which wouldn't break older programs) would be to send an event just before entering the active wait.
This would allow helper procs to get into "mouse_wait_mode" (ie.: they know that they have to do special things, like refreshing the screen, etc)
As soon as the mouse button is released, send another event...

While this is just a workaround, it will allow add-ons to provide DRS and double buffering whithout breaking older gui programs.

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?

That's no real excuse. Yes, you can use the DDraw3 device for systems that don't support higher DDraw versions (and you can even test which version is avaliable via some simple COM querries), but that is hardly an excuse for not even making the attempt.

You can't resize a DDraw4 surface either. That doesn't prevent a DDraw4 app from supporting resizing.

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

Why not, upon click of the mouse, set a global function pointer to whatever needs to be done from this widget, and then upon release of the mouse, run this? Or you could have it run it instantly, and have like this: (taken directly from sources from my project)

careAboutHeld is passed to the function to decide if we should care whether the button was previously held down. If it was, it won't register a keypress until you release, then repress it. chooseHeld is a static var within this function that tells us whether this key is currently held or not. It returns a 1 upon finding a keypress (although if the key was held and it's supposed to careAboutHeld, it will return a 0) and a 0 upon no keypress... perhaps not the best of code but you get the idea.
Therefore, you can still have stuff going on in the background, no need for any locking-up while loops or silly stuff like that.

ahem

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.

Yep, that works. But it's not really backwards compatible...

Agreed.
But if you take a look at the guis which work with double buffering and DRS, they need to override every widget (to ensure that no blocking occurs).

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.

Exactly. You keep making this argument, yet do nothing about it.. Have you even contributed anything to allegro? ie: submitted a patch?

edit: You want it? Do it your self. I don't need it.. Otherwise, I'd probably do it myself. Just like when I needed/wanted alsa midi support, I wrote a patch for allegro and whoopa, it was applied.

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).

Yep. But assume you set screen to an offscreen buffer for double buffering. Since the method doesn't return, you can't blit to the screen, unless you have a dummy proc that blits to the (real) screen.
Hm.. guess I forgot to mention the MSG_IDLE / update method in my list of possibilities above

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);
}

Steve... in case of the button, that won't help you. since update_player() won't return until the button is released... or am I missing something here?

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

Yes. But GTK sucks IMO.

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]