Consider having several event loops, whether the gui is active or not could select one specialized for the gui, another could be for game movement keys, whatever.

The best way to deal with it is to create one event for Allegro, named CAllegroEvent or whatever your naming convention is.

This event will not be available to your users though, unless they explicitly process it. Your event loop will catch this event and create other events for the GUI, like mouse down/mouse up, mouse/move etc.

In this way, you can put other event systems in, if you wish. For example, you could have an CWin32MessageEvent for all Win32 messages, and then have your GUI create the same mouse down/up/move etc events that are also created for CAllegroEvent.

Provide a CCanvas class with drawing methods, selecting pens and brushes, etc. Then let widgets draw to that.

I'll be honest: I don't like it very much.

The user should be allowed to skin widgets, i.e. select all its graphical aspects at runtime.

Create widgets for layout, i.e. integrate the layout mechanism with widgets. Each widget should have its own layout, and a special group of your widgets will be about layout only.

Using a secondary tree of layout objects makes it more difficult to create layouts.

I haven't really found a simpler/better method of widget layouts than what Qt uses. Other than explicit widgets that layout their children.

I do something similar for my little Canva5 library. I used Qt's setup as an example, so its fairly similar:

http://git.tomasu.org/canva5.git/blob/refs/heads/prototype:/core/src/Display.cpp
http://git.tomasu.org/canva5.git/blob/refs/heads/prototype:/core/src/Bitmap.cpp
http://git.tomasu.org/canva5.git/blob/refs/heads/prototype:/core/src/PaintEngine.cpp
http://git.tomasu.org/canva5.git/blob/refs/heads/prototype:/core/src/Drawable.cpp
http://git.tomasu.org/canva5.git/blob/refs/heads/prototype:/core/src/Painter.cpp

I rather like it. All I have to do is implement a new Bitmap class and a new Display class, and a new PaintEngine class and the lib is instantly ported to another backend.

append: One of these days I intend on adding some GUI classes to it. But it can be used as an engine for 2d games quite nicely. Just spam some Item's of various types at the Model, and it'll take care of everything for you. You can even create multiple views into the same world! It's really quite neat.

Being honest doesn't help much if you are not also useful.....

What is it you do not like?
The style of the buttons / sliders / radio / menu / drop down / file browser - what? ? ? ? Of course there will be image buttons so you can make it look whatever way you want it to, and you can define hit boxes. Simple event based system, widgets give messages about what happens and then you cherry pick the messages you want and hook them up to other things. It's also very easy to derive new widgets, all you have to do is implement 3 simple methods, HandleEvent(Event e), Update(double dt), and Display(GraphicsContext gc).

What exactly is this QT style that you all mention? I am not familiar with their source code or programming with their library...

Also, what kind of interface do you like? Constructors with every parameter possible, or basic constructors and specialized setup functions....???

Moose, you are referring to the somewhat javax / swing type widget layout mechanisms? Where you provide a window / container with a layout widget? I will be providing layout widgets this time, the widget handlers will own a layout manager, whether a dumb default one where you can hand place widgets or a smart one that lays out and resizes to fill / fit / align / whatever else you want.....

I think this is simpler and better too. More like Javax and AWT. That way you don't have to memorize long constructor parameters.

Qt has a special layout object you assign to widgets, any widgets. But dedicated layout widgets also work. Same idea. Just so long as you don't force me to layout my gui by hand, I won't hate you.

Since Agui favors Listeners over bubbling messages, the way I did it might not be exactly what you need (since I think you mentioned integrating your messages?)

But here is basically how I did it.

I have a base class Image, Font, Font Loader, Image Loader, Graphics Context...

I expect the back-end to implement all of these.

The loaders are pretty straight forward:

  class AGUI_BACKEND_DECLSPEC Allegro5FontLoader :
    public FontLoader
  {
  public:
    Allegro5FontLoader(void) {}
    ~Allegro5FontLoader(void) {}

    virtual Font* loadFont(const std::string &fileName, int height);
  };

They implement the base class's load method and return an abstract Font, Image, etc.

The way Input works is as follows.
I have a base input class that allows you to queue up Mouse and Keyboard events.

The Input Handler base looks like:

The way this works is, there is a Gui object that handles just about everything event related. It takes in an Input and GraphicsContext.
Example:

What the Gui does with this Input is:
In each logic() update it:
-calls input->poll()
-dequeues and dispatches queued, abstracted input.

It is the backend implementation's responsibility to convert whatever input it receives into agui::MouseInput and agui::KeyboardInput.

Now, in a case of A4 or SDL 1.2, the Input::poll() method would be implemented.

In an event driven style such as A5, I created a processInput(ALLEGRO_EVENT& evt).

That is called like this:

That is the basic idea... create an abstract set of functionality that any backend should be able to support, then implement it as a subclass and use polymorphism (and casting) to do the backend specific action.

As for Layouts, I probably should have made every Widget own a layout, but instead I made it so that a Layout has complete control over the Widgets it is laying out.

I prefer the idea of every Widget having a layout, and preferably a NULL layout can be supported.

As to what you should work on with it... I guess games or level editors...

I like your GUI, I think it looks quite nice. The default skin doesn't matter anyways :p

Take Agui for example, it looks much nicer in action!

{"name":"607025","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/5\/c5f02ac525f2c373d6fa7ae914a70bf9.png","w":476,"h":281,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/5\/c5f02ac525f2c373d6fa7ae914a70bf9"}

ie: listeners?

It's just a default style. You can style it any way you want, or at least you will be able to. I'm going to shuffle things around a bit now and let the user create the gui components themselves, like scroll bar buttons and scrollers. So you can make it look just like OSX if you want to. I'm not going to try and create system themes, but I should have a mechanism for loading guis from script files so the user could write their own system themes.

@Everyone
Should I include support for nine patches, for dynamic resizing of images?

What is your favorite way to design a gui? Would you like a widget placement editor? Ie.. a gui editor?

Would writing handlers for extra large video bitmaps that the gpu can't handle be useful to anyone? Do you want support for large video bitmaps? (Made up of several smaller video bitmaps and pieced together like a jigsaw)

@Jmasterx
What is the AGUI_BACKEND_DECLSPEC declaration for? Do you need that for building on different platforms?

For my input I decided to follow A5 and use a EagleEventHandler base class along with base classes for system, graphics context, timers, and input. Every backend has to implement these to function.

void Scene::processGuiInputEvent( ALLEGRO_EVENT* evt )
  {
    m_a5GuiInput.processEvent(*evt);
  }

Doesn't this make your library depend on A5?

No, because processEvent(ALLEGRO_EVENT* ...) is a method that is specific to Allero5Input class.

The GUI is only aware of the Input class.

If you used Agui with SDL you might have an SDLInput which might have processEvent(SDL_EVENT*...)

agui::Allegro5Input::processEvent(...) calls Input::queueMouseEvent and queueKeyboardEvent. So there is no dependency on Allegro5.

These are generically dequeued in Gui::logic();

In my example, my game uses Allegro5 to power it so I find it acceptable to make Allegro5 calls in it.

But Agui itself can be compiled without any exteral libraries, check out the cmake file.

The DECL_SPEC allow the library to be compiled as static or as a DLL; MSVC requires each class to be exported using _declspec when building as a DLL. I have 1 for core and 1 for backend to avoid conflicts in certain compilation situations.

But because of how MSVCRT and such work, I don't recommend anyone use agui as a DLL unless you're using the exact same runtime. But it does work.

Agui has nine patch support if you want to look into that. It is incredibly useful if you're going to support layouts.

The way you do it is how I did it too. I also mapped the gui to Allegro5

I looked over the code you committed and it looks fine. I didn't find Widgets but I guess you'll add those soon.