So like the title says, I am trying to figure out the best method to abstract Allegro 5's event system into my own event system for use with my GUI. My GUI also needs to be compatible with other libraries like SDL / SFML / what the hell ever else someone wants a port of.... as well.

So, my first thought is to duplicate Allegro, so that A5 users don't have to adjust much to use my GUI's event system. This would mean copying most ALLEGRO_EVENT_BLAH_BLAH into EAGLE_EVENT_BLAH_BLAH and duplicating the event union and structures.

The main focus right now is to get the abstraction ready, so I can fill in the backend for Allegro 5 and start porting all my widgets to the new library.

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.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

Does anybody have any ideas for abstracting graphics libraries? I know theres AGUI, who wrote that again?

Here's what my gui looks like now, with A4 driving it :{"name":"607020","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/0\/f06a193524d99eb5d5a68d3eacf3de3f.png","w":812,"h":632,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/0\/f06a193524d99eb5d5a68d3eacf3de3f"}

Do you like the way it looks? What options should a user have when drawing widgets in a gui library?

What is the best way to integrate layout managers? Give every widget handler (frame / window / subwindow) a layout manager?

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.

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

I'd say that's the same mistaken believe which makes CSS as hard as it is. <table><tr><td> elements in HTML are extremely simple, everyone can for example make a 3 column layout in a minute. CSS on the other hand is not simple at all, a 3 column layout requires hours of research.

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.

I really like the Qt/GTK+ design. It requires much less compile-and-test sequences since most of the layout is calculated automatically. The alternative would be a GUI designer, but I tend to find WYSIWYG output hideous.

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

It provides a dynamic layout mechanism. For the most part there is no hand placement of widgets.

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

Quote:

I'd go with simple ctors and a bunch of methods.

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

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

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.

Ah, jmasterx, there you are. So how did you achieve your abstraction of the graphics backend in your library agui? Virtual systems? What is your opinion on my gui and what do you think I should work on with it?

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

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.

@EveryoneShould 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)

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

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.

Well, I decided to just make a thin wrapper over EagleEvent's. The events and the keycodes and everything mesh with allegro - ALLEGRO_EVENT_KEY_UP is now EAGLE_EVENT_KEY_UP and so on.... So I guess it will just be a superset of all the library backends it supports.

Yeah, I haven't ported any widgets yet, first I have to finish the backend for A5 and then I can rebuild my gui on top of it. I shouldn't have to change a lot to port my widgets, but I will have to change all the drawing routines, and their input checks will change to use events. So, a little modification is necessary.