I can't compile the source though, or is it even ready to compile, I get an error that list cannot be found on #include <list>
I'm compiling with this:
D:\unzipped\algui[1]>g++ -c -I./include src/widget.cpp
and a bunch of syntax errors follow.

Anyway algui sounds appropriate for a name... but any other suggestions or maybe a codename ... that'd be cool.

spellcaster, have you also realized that the previous "projects" for new guis or other larg projects never got off the ground because noone actually started? I tihnk this is a good thing, show some code, and debate, at least then theres "something".. instead of a bunch of hot air.

That's my point. So it won't be a team project, but we'll all start doing our own thing. Again.

Regarding your design, my major problem is that BITMAPs are not hidden. Another point is the way common gfx operation are perfromed directly.

But, as you said, time is money, and you have spend a lot of time thinking on this matter already.

I'll be glad to use your GUI lib as soon as it's finished.

Don't get me wrong folks, but exactly this is why group projects die very youg here all the time. A single developer might be able to jump start a project. He might even be able to finish it, even if he doesn't have a design (besides the idea in his head), but for a team project, this just doesn't work.

Like I said before, we all have spent quite a few time thinking about this topic. We all have worked with guis and developed our own enhancements, add-on or own systems.

But if we just say "here's my code. take a look, discuss it, but I'll do my stuff anyway" we'll end up with one gui lib per person.

If this is what you want, ok

Sorry, but I don't understand what you mean. If you mean that drawing should be abstracted, like Windows drawing on a device context, my opinion is that it should not, for the following reasons:

1) All allegro drawing must be encapsulated within a class. Too much work.

2) Too many indirection layers. Drawing a simple line will call the virtual method of the class, which in turn will add the widget's screen position to the line's coordinates, then use Allegro to draw, which will redirect the call to the BITMAP's vtable, which in turn will use DirectX or GDI or xlib to draw...

I don't think Allegro should be hidden, because there is a lot of functionality that needs to be wrapped up and this is quite tricky since it is not easy to tell what one might need upfront. I am not for a generic GUI toolkit, since it is quite difficult to achieve.

As I stated earlier, I am open to suggestions. (But I don't see any). Therefore, I am gonna proceed on my own, and whoever wants to jump in, is welcomed.

I've opened a sourceforge project. When I finish the event handling, I'll notify you of the link.

Spellcaster, was it you who emailed me about my gui? Sory, I've just been having a rough time..

Hm.. the only thing you could interpreted as nitpicking was the frame/window discussion... and if you take at my post (the one before your post) I had already explained the meaning of words... but, anyway... I always like a good argument

Um, why?
Don't you think there's a reason almost every gui there is has a dirty rect system?
And even if you think your applications don't need a DR system, why do you think it's bad?

Either you're saying "I'm blitting only the part I'm blitting" or you're saying "I'm only blitting the part that has changed".
The first one makes no sense, the second one is either a DR system or pretty inefficient.

Again, what you're doing here is to limit yourself for no particular reason.
If your game has a "play area" and "status/ control" area, only the game area needs to be repainted every frame. No need to blit the complete GUI if only one button has changed.

Also, the DR system would allow you also to invalidate parts of the GUI. Assume that your game draws something over the gui (say for a tutorial, or a very special effect).

Well you can blit everything, but why should you?

And even if you don't like DR systems, why do you force everybody not to use them?

People have written what they'd like to see in there gui of choice. Obviously stuff like animation is wanted. Obviously you don't care.
That's fine. As I said, do your own thing. That's ok and no problem at all.

You do realize that the whole idea of a group discussion is to get the idea of the group?
It's ok if you have a closed mind and a ficed feature set. But don't try to enforce it. First off all, it won't work, and secondly it's pretty pointless.

Regarding your idea of a Font doing text output... well, your choice. You're mixing here two different things though, but it's your GUI, so you're free to do what you want.

I could give you a couple of reasons why this is bad, and in what limits this will impose on you, but I'm quite sure that you have considered this already and dismissed it as "not needed".

You do realize that this can be done with the methods I listed a Context capable of holding a state?

Besides the goroud shading But I'd say that a simple gradient floodfill should do the trick as well. No need to add 3d routines to a standard title bar.

The idea is to maintain a small interface, not to bloat it. If you list these drawing routines, and then start to group them by category, and then take a look at the similarities and differences, you're one step closer to a design.

Just a small example: Your sunken/raisen stuff. You do realise that if you have a shadedRect() or something a sunken and raised border is painted by the same routine, just with different parameters?

And that a "skin blit" is just a blit?
Don't make things more complicated than they are... try to make your interface simple

No comment on that one. But I added it to my list of possible sigs

I won't quote Prachett here, but it's very tempting.

Regarding adding widgets to dialogs: Of course you can do this. Requires you some minor tweaking of your DIALOG struct, but it works fine. Same for most other stuff on your list.

And the remaining feature are just layout / container related

As I said, you can implement what ever you want. As you said it's your GUI. I don't want to convince you, it's your code, your lib, feel free to do what ever you want.
But you do realize that this thread was about collecting ideas for a new gui. Designed and implemented in a team effort? And "Team" and "my gui" don't mix well

I see no point in jumping on your "wagon". As you pointed out already, it's your GUI. You also seem to be very convinced of your design. Well, I'm not. I've also explained what's limiting your approach.

You do realize that thes points have been addressed already? You did read the posts in this thread, right?
YOu do also realize, that the updating problem is the most limiting factor in the current gui?

You do also realize, that the proposed event model, with the outline event flow will keep track of input focus?

No need to point that out. It was pretty obvious already.

You really think that thi is about your GUI, don't you?

But I agree, that after this discussion, the chances are pretty bad to get team effort towards an allegro gui on the way.

Nope. You took every line that I wrote and replied to it. And the replies were not that good.

Well, no real GUI has a dirty rectangle system: MS Windows, X-Windows, the Photon MicroGUI, the OpenWindows, the NEWS system all use regions.

MASKinG has dirty rectangles, because it implements animation on the desktop.

I did not say it is bad, I said it is unecessary. Let me repeat the reason:

Only the affected area is double-buffered.

I am not limiting anything. Perhaps you have not understood my update system. Let me go through it, one more time:

A. there are two buffers at each given time: the screen, and a back buffer.

B. widgets draw on the back buffer; widgets behind them are redrawn and widgets above them are also redrawn on the back buffer; the end result is blitted on the screen.

C. Only the area affected by the redrawn widget is blitted to the screen.

So, if a button is updated, it will draw itself either directly to the screen, or to the back buffer. Then, the library will blit to the screen the affected area.

There are two cases here:

1. The button's state change is immediately drawn to the screen. This happens automatically when there is no back buffer.

2. The button's state change is immediately drawn to the buffer. This happens automatically when there is a back buffer.

Now, if there is a buffer that the game draws onto, you can:

1. Either draw the GUI directly to the screen, but have the special effect blitted from some other buffer.

2. Or draw the GUI on the widget back buffer, which will blit itself to the screen.

3. Or draw the GUI on the game buffer, using screen = game buffer, then blit the game buffer to the real screen.

I don't see any other case. So, I don't think there is a need for a dirty rectangle system.

People have also stated that they need tools to write their games, and almost everyone has tried his own version of a tilemap editor, with no particular success, due to the lack of a good gui.

A GUI toolkit for writing Allegro tools is a priority over a GUI toolkit for games. How many games need special effects and combo boxes, for example ?

I think there is small minority that needs special FX in the GUI. And if you need it so badly, you can always animate widgets by the traditional way, i.e. change their state and geometry.

And even if you do want so much special effects, I have told you that it is the easiest thing to add a DRS system to my design. There is a method called 'redraw' which draws either directly to the screen or to the back buffer. The last line calls 'blit' to blit the back buffer to the screen. You can replace this call with a call to the DRS system.

The next version of my class will have it, so as that I prove to you that it is the easiest thing to do.

Yes, but how you can quicly draw a gradient floodfill ? Instead of making your own routine using Allegro, you can use 'quad3d' and achieve the same result.

But I am the one who doesn't want a 'GraphicsContext' class for avoid the bloat!!!

Besides that, you don't have any other example.

It seems that you have not try skinning. Skin blit is not just a blit: it is a routine that creates 9 sub-bitmaps of the skin bitmap, uses the outer subbitmaps for the borders, and the inner one for the filling. Check out MASKinG. It's easy to talk when you don't know shit.

Feel free to put it!!! and put my name next to it, but don't forget to put the rest of the text too...because it might look silly out of context, but I talked about COMBINATIONS of drawing calls and the ONE MORE LAYER that it will make it super slow.

It's my gui because I designed it and wrote it so far. If you participate, it will be 'our gui'. Simple, isn't it ?

Nope, you did not explain. You just said "other systems use DRS, so yours should also do the same" without justifying why.

As I said earlier, I am posting the code for demonstration reasons. I want people to look at it and say "ok, here is a bright idea, for so and so reasons", or "here is a silly idea, for so and so reasons". But I want arguments, no silly 'others do it this way, so we must do it that way'...

Geometry management ? were ? I am the only person that talks about it. I must be the only one then that gets irritated for having to specify each widget's geometry by hand!!!

I don't want to be ironic. Let's keep the discussion in a good level.

I did not see any post about "event flow" or "input focus". I am not sure about what you mean, but I have already implemented it and it is indepentent of the event flow: you can change it by hand, if that is necessary.

You haven't realize a hidden trap in the focus management: that of toplevel windows coming forward when a control is clicked. In my widget class, when a widget gets the focus, all ancestor widgets are notified that a descentant of them got the focus. By this way, they can bring themselves forward and/or change their appearance, without ever knowing if they are toplevel or not.

This is quite a good design, don't you think ? I have never anywhere else someone talk about it, though.

<quote>
You really think that thi is about your GUI, don't you?

But I agree, that after this discussion, the chances are pretty bad to get team effort towards an allegro gui on the way.
<quote>

It's not about 'my gui', its about Allegro not having enough game tools or an easy way to write one.

That's not nitpicking

*cough*

Yes, but the idea isn't to help you with your GUI, it's to get a design most people can agree and collaberate on.

Anyway, it looks like everyone's just going to write there own (which is about what happened last time this came up) so I guess we'll just see who can put their money where their mouth is. I was thinking of writing a GUI lib too, but since everyone praises Swing, maybe I'll wait until I've gotten into Java before I begin with an inferior design (I was just going to (mostly) emulate Win32) ...

What is a region, you ask ? a region is a table of rectangles that represent the visible portion of a window. All drawing operations are clipped within each rectangle of a region. Each time a window appears, disappears or resizes, the windows below get a new region.

In case you truly want to learn how regions work, have a look at MxWindows (which I wrote 3 years ago).

Basically, everything revolves around understanding how to 'subtract' a rectangle from another rectangle.

Let's say we have two rectangles, A and B. The operation A - B can have the following results:

No rectangle if B totally overlaps A.
1 rectangle if B overlaps half of A.
2 rectangles if B overlaps one quarter of A.
3 rectangles if B overlaps some side of A partially.
4 rectangles if B overlaps part of A but it is completely inside of A.

So, after the subtraction, the result set of rectangles is kept in a table, called a REGION.

Professional window systems use regions to make Windowing possible. Regions were first used in Apple's Quickdraw, back in the 80s.

A clever Dirty Rectangle System will use the same algorithm for overlapping updatable portions. When using a DRS, there is only one region that is calculated as the programmer adds dirty rectangles to it.

I have done a dirty rectangle system in 1996, where I wrote a MsPacMan conversion for DOS in Turbo Pascal 6 (which got me the first prize in the PC Master magazine!!! after two months, the excellent Pc-Pac and Pc-MsPac came out, and then after few months MAME was a reality...).

Ok, forget my library (which is not a library at all, just a class). I am all ears.

Sorry mate. I understand that you did quite a big amount of work. But, for example, can I take your tilemap editor to Linux ? Nope...because its a win32 only app.

I hope you understand now that a decent GUI lib for Allegro is needed.

But that's what I said. But...what is better than to communicate ideas other than the source code itself ?

Ooops. I didn't expect that people will think that I did not do a good design. As I have told before, I have made more than 50 tries to write a good gui. I have big experience with guis, and I know Win32, MFC, Qt, Swing, Photon, XLib and Motif/Lesstif.

Ok guys, as I said before, forget my library. I will personally use it as a testbed for new ideas. But...

Lets make a GUI, shall we ?

Sooner or later you will face the same problems as I did. And I can tell you, the drawing mechanism is the least of the problems. I can guarantee you that.

Ok, here are the requirements for now:

1) DRS (I hope Spell is happy now)
2) A graphics abstraction layer

Anything else ?

Ok pardon my ignorance with DRS and regions, but we should all be open to ideas, and I have to give Axilimar credit if he did design or use all of those GUI's. Unfortunatly for me anyway a lot of this terminology goes over my head at times because I've never heard of it or implimented it myself. I guess I'd be more helpful for implimenting the stuff on top of the widget subsystem but I hope my discussion on how to impliment multiple theme types such as BeOS/Windows/Mac helped some. Another thing was the font class you had implimented with alfont, a simple textout won't really do it since that has no way of doing the && special character shortcut, text shadows (think beveled disabled text in windows), bold/italic/underline text, fixed width output, centered/right justified text, and maybe a way to justify it by clipping or adding the "..." at the end to make it fit. A font GUI class should be able to support at least that. I've managed in my lib to bring it down to a single function that handles everything via a bitwise flags variable. Another way would be a tagged text method where the format of the text is encoded within the text string that is sent in. I've had discussions on this implimentation myself and both methods have strong and weak ponts, the latter is better for a wordpad type application for example but would just call the first function within as new tags are read and set. Also a way to support multiple fonts should be implimented though the best way to do so is soemthing I have yet to figure out as well.

Ok with that said and Axilmar's apology lets keep this going please My first complaint though is that allegro shouldn't be the place for really decent discussion, remember it's post, wait, reply, wait which is a bottleneck. Is there some other way for realtime discussion and a way to post ideas/code snippets. Maybe a channel should be opened on IRC such as #algui or something where we can all get some realtime discussion going.

Also Axilmar remember that I'm rusty on C++, I have nothing against using it, but don't make it pure C++ or we will limit those who do not wish to switch to C++ just to use a lib. Also STL is broken on MingW so your <list> will need to be addressed, or is it just my install that's bad?

Anyway I'm glad to see this kind of flexibility, I thought you were just going to move on with your own implimentation but I'm glad things turned around for the best. For now though I'm going to read up on regions and how they fit in. Also if you want some quick region code look to me or Miran, we've both written code to split regions into non-overlapping regions/rectangles for our DRS implimentation. I do mine slightly differently though keeping the rectangles as wide as possible for scan line optimization.

I would be VERY interested in seeing your system, axilmar. Just so you know.

Oh, and I remembered some more examples where action and a GUI system is required at the same time - MMORPGs. Look at Asheron's Call, or Tibia, or any other recent MMORPG, and you'll see what I mean.

Ok, here it is in the form of zipped source code(attached file which contains html help in the 'docs' directory: file 'index.html').

The DRS is enabled: every half second the screen is updated. See method 'setUpdateCallback'.

Press and hold the left button down over a widget and move it around with the mouse.

You can also change the video mode by using Alt+1, Alt+2, Alt+3 keys. You can exit the app by pressing Alt+X. All these are set using 'setAccelerator' at the root widget.

There are many other thing to see:

1) drag-n-drop (search for the 'beginDragAndDrop' call). Data query and exchange are done through the 'queryData' and 'getData' widget methods applied on the widget retrieved by the 'Widget::dragAndDropSourceWidget()' method.

2) event handling: uncomment 'textout' and 'textprintf' in the event handling methods to see event output as it happens.

3) geometry management: some widgets are maximized and always follow the size of the parents, some widgets enforce a specific layout on their children.

4) event grabbing: when you press a button over a widget, it grabs events, then it moves itself around on 'processGrabbedEvent' method. This allows for a widget to control the event flow without leaving the main event loop. My menus will be implemented like this.

5) focus management: press tab, tab+shift or the cursor keys to move the focus around. Widgets with the focus draw themselves with a thick black border. If you search the code, you will see that the focus goes to instances of the Test class that don't have children (method 'focusable()'.

6) sloppy focus: uncomment the line 'Event::setFocusFollowsMouse'.

7) timers: widget 'form1' has a timer that is called every 1 second. This will allow blinking cursors, button repeaters, autoscrolling when the mouse arrives at widget edges etc.

8) left handed mouse: uncomment the line with the call to 'setLeftHandedMouse'.

9) multiple clicks. The left button up handler prints the number of clicks. You can use 'Event::resetClicks()' to restrict the amount of clicks to 2 in each widget.

If I ever finish this library (highly impropable, since no one is willing to lend a hand), it will not use DRS by default, it will use double buffering, since the purpose of this library is to build Allegro tools.

(Right now I am off to designing my widget classes. If a development team is made to make the ultimate allegro gui, I will be very happy to participate and give a hand. When this happens, I will abandon my gui.)

PS: This work is the culmination of 7 years experience with guis.

I wrote it last week, Richard. As I have told earlier, I have done more than 50 tries to reach this state, so I was pretty sure of where to go. It's an amalgamation of various solutions I discovered on the go.

If people help me with this code, it will be finished. If people don't help me with this code, but they decide they will start from scratch, I will abandon mine and offer my workforce to the common cause.