That seems problematic if you want a clean interface. I like the way my WidgetMsg class works. It wraps a WidgetBase*, an unsigned int for the topic, and an unsigned int for the message.

Then when you want to connect functionality, you check the gui queue for a WidgetMsg matching your source and topic and message.

while (gui.HasMessages()) {
   WidgetMsg wmsg = gui.TakeNextMessage();
   if (wmsg == WidgetMsg(&mybutton , TOPIC_BUTTON_WIDGET , BUTTON_CLICKED)) {
      /// user pressed our special button, do something
   }
}

This actually gives me an idea to combine widget messaging with signals.

Say you have the following structure :

std::map<WidgetMsg , WidgetCallbackFunctionList> dispatcher;

then you could do the following to connect a signal :

dispatcher[WidgetMsg(&mybutton , TOPIC_DIALOG , BUTTON_CLICKED)] = [&gui](){gui.Close();};

And you could execute it with :

dispatcher.execute_callbacks(gui.TakeNextMessage());

And all the slots would be signalled automagically.

That's the one drawback of my system, the potential for long message processing code.

I applaud your attempt to keep code organized and clean, but the way it is, its pretty messy. My attempts to do this in my own gui have met with moderate success. I have abstracted away background and style into a WidgetPainter class. Every widget has a reference to a WidgetPainter and it takes care of drawing its basics like the padding, border, and margin, and any background it might have.

It's a good idea to separate out 'generic' drawing functions, so that your widgets can use them in combination to draw themselves. I appreciate what you want to do style wise, but I think it would be good to reconsider how to go about doing that.

I just made a major commit to Eagle core branch. I finished reworking my gui classes to use the new WidgetBase class. It should simplify things greatly. Now I need to do some serious testing. Still got a shit ton of TODO items. I wonder if I'm ever going to release Eagle. I've been working on this for so long now, almost 10 years. I think after I get done stress testing stuff I'm going to make a feature freeze and start work on the build system and documentation. Gotta make a release.

Swipes should be fairly easy. Implement a camera that you can scroll the view of, and then listen for touch events and move the camera. Nothing needs to change position except for the view. You then have to account for the view offset when sending touch or mouse events to the widgets though. In my GUI I allow for middle mouse button drag scrolling of the view. Just have your top level widget monitor for swipes, set the view, and offset the event positions by the view.

I've been reading your signal.h header and I seem to have a basic grasp of what is going on. Not sure what is going on with delayed emitting. Tell me, you used variadic templates to pass a variable set of arguments, correct? And I see you did some kind of overloading for const and non const member functions, but I don't follow it very well. Is that C++ 14? My library is still C++11, are things like that possible in C++11?

I've had a bad case of feature creep over the last few years. It's not a bad thing in and of itself, but it means you're constantly in development phase, and not release mode.

So far my GUI has gone through 3 major phases. First version worked with Allegro 4 only. This was during the period when Allegro 4 was being phased out in favor of the new Allegro 5 branch. I decided I needed to remove any direct dependencies on third party libraries through abstracting away all the interfaces and hiding Allegro inside an Eagle system driver. My latest phase is a total redo of the WidgetBase class and everything that goes with it. I've made things much simpler, much more extensible, and much more flexible.

I've been reading quite a few of this forums old gui threads, and man. Everybody gets all excited - "Hey let's make a GUI!" and then there are like 5 pages of arguments about C vs C++ and how best to design the library. axilmar and I have gone at it a few times about gui design. He's got extensive experience with guis and a GUI library of his own. I believe it's been long abandoned though. Let me check. Yep, ALGUI is gone. axilmar took it down off github.

Long story short, the Ultimate GUI for Allegro has been an elusive target.

There should be a predefined time when your slots get signaled. I don't see the need for making sure you don't add a slot when it's being signaled. For example in my gui, the only time a widget can raise an event is during HandleEvent or Update. Makes everything so much simpler and easier than worrying about contention.

I just found EGG_DIALOG, Evert's old A4 style gui for Allegro 5. Neat.

I've finished my main upgrade and refactor on the core branch. Almost ready to merge back in with master.

But now I've got two dilemmas.

1) Most layouts do not automatically size a widget. Their size must be set according to the rules of the layout.

2) All widgets must be drawn within their parent's inner areas. This causes problems when I want to make a widget with separate parts, like a drop down list. I can add the list box and the drop down box separately no problem, but what area should the parent have? It doesn't make sense. So I need a way to add just the children when the parent is tracked by the widget handler (gui).

How do you deal with these problems in your gui frank.n?

make doc didn't work for me last time but mysteriously it did this time.

A better explanation would be, each layout has a set of areas defined by the layout's rules. For example, a Pin layout stores a position and an alignment, and never resizes a widget. Another example is the Relative layout, which stores areas as fractional areas of the parent. The Grid layout stores grid positions, etc.... But in each case they store their own kind of layout position, which needs to be set before a widget attached to that position can receive an area.

In my gui, all children explicitly receive their position and dimensions from their parent, which is either another widget, or a layout.

Some layouts allow reposition, some allow resize, some allow both. But none of them know how to set their widget's area until 1) Their area is set, and 2) Their layout position is set.

axilmar and I got into a big semantics argument over the difference between a minimum size and a preferred size, but that's another story.

I've come up with an idea, and that is for my layouts to store elements of a layout position base class. Then I can derive the sub class from the base layout element, and add dynamic layout positions to a standard layout class. Move the inheritance from the Layout class to the LayoutElement class. This would also allow me to mix and match layout elements. I think it could be very powerful.

But of course, I've got lots of other things to do. I need to work on my scripting interface, I need more widgets, want to finish my resource manager, etc...

In my gui, a 'modal' widget is as simple as a widget that always consumes the input as long as it has the focus. I can return DIALOG_INPUT_USED from my HandleEvent function, and that has the same effect as making it a modal widget. Don't be greedy with the input if you don't have focus though!!

EDIT
Question; How long did it take you to make custom docs with doxygen? I plan on using doxygen when I'm ready to make docs, but I don't have any experience with customizing the output. Also, it threw tons of errors during the make process, but managed to complete anyway, so I guess they were more warnings...

I was referring to your .dox file for the layout. The format seems simple enough.