By that definition, all unfinished code is redundant. Edgar's abstraction layer is simply incomplete.

You may also want to abstract away cursors. For example, Agui sets the cursor when mouse enters textbox. Possibly also transformations. Timers can be useful too but may be harder to abstract.

Transformations are useful if say, the native buffer size is 640x480 and the user goes fullscreen with that bitmap. You want the mouse to still correctly detect widgets.

Supporting UTF-8 is nice too.

For features, it could have all 3 messaging styles like QT:
-Messages
-Listeners
-Signal Slot

How you handle skinning is important too.

It would be nice if:
In the simple case, users can just supply bitmaps for each Widget (or one big one like GWEN allows). But in the more advanced case, the user should be able to override how a Widget both: Paints its background and its component.

When making Agui I realized the importance of having both.

This is where the idea of margins came into play.

So for skinning, all rendering could be done possibly using the Visitor design pattern http://en.wikipedia.org/wiki/Visitor_pattern or by creating a class with virtual methods: buttonPaintBackground(Graphics& g) ... etc.

This way the user can skin without subclassing all the widgets (One of the pitfalls of Agui).

Another interesting problem you need to think about is:

How do events bubble up. This is sort of another pitfall in Agui.

The event in Agui goes straight to the designated widget and all attached listeners.

But what happens if you have a TextBox with a scrollbar inside. The textbox needs to scroll itself when the scrollbar is scrolled. The only somewhat ugly way to do this in Agui is for the textbox to internally attach a listener to its scrollbar.(The even better way is to put it in a scroll panel).

There are a few better ways to handle this. Some GUIs send the event to the parent first, then if the parent is not interested, it is sent to the widget itself. Other guis will use the chain pattern:
http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern

You will need to decide what is best and how listeners should consume events, etc.

Where this went most horribly wrong in Agui is my ScrollPanel widget. It attaches all kinds of listeners to its children to detect when to show / hide the scrollbars.

What are you talking about? Event sources copied 1:1? Here is my EagleEventSource header :

That is certainly not a 1:1 copy of anything.

And if you're talking about using ALLEGRO_EVENT_QUEUE's inside the Allegro5EventHandler, why not? It's an a5 driver, it should be using a5 functionality. I used the same names and values for events to make it easier to port from a5 to my library. All they have to do is rename their events to EAGLE_ instead of ALLEGRO_. And the id values are the same so I can just perform a simple assignment of the variable value instead of having to map to different values. :/ That is pretty much the only thing that is the same about my library and allegro 5. If I didn't use ALLEGRO_EVENT_QUEUE's internally I would have had to implement a separate thread for every input source instead of one thread per event handler. And I would have had to implement some version of locking and sleeping using pthreads on top of it then.

I attached both Events.hpp and Allegro5EventHandler.hpp. Look for yourself and see.

The document looks good. However, I have an alternate suggestion for skinning. You seem to imply that the Widget class has a virtual setSkin. This means the user needs to subclass the Skin class for each widget they want to custom render since it is per-Widget. Instead, it might be better if you have setSkin in your Gui class of sorts. This way calling gui.render() will actually do:

for each widget
widget.paintBackground(skin,g);
widget.paintComponent(skin,g);
...
Widget::paintBackground(Skin s, Graphics g)
{
   s.paintBackground(this,g);
}

This sort of thing is possible with the visitor pattern and double dispatch.

A user should be able to subclass Skin and custom paint any and all widgets without having to subclass the skin class for each widget.

Your way may be able to do this and I may have misunderstood. I apologize if I did. But one of the caveats of Agui is having to subclass all Widgets just to paint them in a custom way. It would be cool to have something more like Java Swing.

Design doc looks like a great start.

Requested Additions:

-drag and drop.
could we also support DnD across different ALLEGRO_DISPLAY's?

-a default event loop to give control to GUI

-input injection methods for all input devices.
for people who want to manage input themselves

-gesture support
phase #1: as supported by platform

I have added drag and drop and gestures.

Edgar, are you in?

With this technique, how do you deal with ninepatch backgrounds? Ninepatch is very important for drawing backgrounds. How will you differentiate from a normal resource and a ninepatch resource?

Other silly little things that come to mind: What if a user only wants a 2 state button, and does not want to provide a focus texture, a highlight texture, and a disabled texture. Will this do something like:

If has resource loaded for state, use it, else, use default resource.

I also wanted to note a rare case: In my card game, I have a Widget that renders a bitmap that has some opaque and some transparent areas on top of what is normally rendered and then Widgets are rendered on top of that:
{"name":"608312","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/d\/ed789bc69f8058a6d5941a8c020a6b82.png","w":858,"h":939,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/d\/ed789bc69f8058a6d5941a8c020a6b82"}

Ofcourse the user could just override paint methods to achieve this, but, it is a case where subclassing a widget is needed to paint.

Your method is simpler and easier for 95% of cases, but introduces subclassing in rare cases. That's not a problem, but I wanted to bring that sort of weird corner case to your attention.

That brings another feature to mind:

It would be good to have a visibility clipping mechanism. For example, being able to put a ListBox in a ScrollPanel and have the ListBox only render items visible to the user. In Agui, since scrollable widgets directly take in scroll bars in their constructor this is easy to do, but it would be better to have it generalized.

Yeah, I agree. I was overkill-trying to separate logic and presentation

Oh just thought of another feature I like: resizeToContents in the base widget (or an interface IResizable if you prefer coding to interfaces).

The ace of Spades container is weird because you essentially have:
Paint the inner children
Paint the ace
Paint the outer children

Actually, now that I remember how I did it:

I have a class Frame in Agui which allows me to put Widgets in the frame's content panel, and in the frame itself.

So the X, cancel and Okay are Widgets of the frame while the inner ones, scrollbar and options are widgets of the content panel.

In this strange scenario, I had to subclass my Frame so that I can do this painthing:
Paint the content panel
Paint the ace image
Paint the Frame's children

Which, now that I think about it, is a scenario where subclassing is pretty much unavoidable.

I was wondering, since each Widget has a setSkin method, who calls setSkin? Is it the Gui class that has the current skin and gives it to the widget when it is added?

What happens in the case where the skin of the entire gui were to be changed at runtime. Is this possible in a singe line of code?

I'm thinking of Java's Swing where the look and feel of the entire gui can be dynamically changed very easily.

That's cool!

I am willing to discuss them. Which one would you like to discuss?

An open source one, of course.

I prefer the event handler pattern:

• a base class named 'EventHandler' contains a method 'virtual void handleEvent(const EventPtr &event)' that allows it to handle incoming events.

• a class named 'EventDispatcher' that is derived from class 'EventHandler' allows external classes to attach event handling functions to an object.

• a class named 'DisplayObjectContainer' that is derived from class 'EventDispatcher' propagates GUI events from parent to children.

I.e.:

The above design has all the advantages of widget messages, listeners and signals and slots, and more:

1. it allows messages to be passed from one widget to another or from an external object to a widget.

2. it provides a listener interface.

3. the listener interface works as a signal and slot mechanism, since external objects can attach listeners to objects.

4. if the event is a GUI event, then it allows the creation of modal widgets without a modal loop since widgets lower in the hierarchy can block events of widgets higher in the hierarchy without the addition of special panels.

5. it allows for propagating down and bubbling up of events: a display object container can choose not to propagate an event to its children or process the event after the children have processed the event.

EDIT: fixed inheritance of EventDispatcher from EventHandler.