So I've written a GUI using Allegro 5 (C++ 11/14).
Aiming for a lightweight approach at first, it has grown a bit over time.

Features

• easy to use signals & slots to connect widgets (just register something callable)

• two pass layout system, Android style; separate widgets and layouts, nestable layouts

• drawing done in separate style classes

• internal drag and drop

• modal widgets, GUI stacks

• event filters

• 9-patch images

Widgets implemented

• Widget, Frame

• BasicContainer, PaddedContainer, Container, WrapWidget

• TextField, TextBox, Spinner

• Slider

• DropDown

• ScrollArea, ScrollBar

• PushButton, CheckBox, RadioButton, ImageButton

• TextLabel, WordWrapTextLabel, ImageLabel

• ListBox, StringListView

• TabWidget, Tab, TabBar

Layouts implemented

• HBoxLayout, VBoxLayout

• FlowLayout, SortedFlowLayout

• RelativeLayout

• SimpleTableLayout

Test program
There is also a test program demonstrating most of the widgets - if you give it a try, do not forget to resize the window
I've managed to get the test program to run on Android, but there is no special mobile code (yet).

Appearance
There is currently a dark-themed and a bright-themed default style drawn with Allegro 5 primitives.
A skinned style has been in the works, but will not be finished any time soon (I'm not any good at making good looking skins).

Screenshots:
{"name":"611662","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/3\/030cbee0edeee88d24cac49314c4e043.png","w":1024,"h":575,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/3\/030cbee0edeee88d24cac49314c4e043"}
{"name":"611661","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/2\/9290352b727cbe011a847ffe47d4c150.png","w":1024,"h":576,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/2\/9290352b727cbe011a847ffe47d4c150"}

Documentation
Doxygen generated documentation is available including a rather verbose main page explaining some of the intricacies. The documentation is not formally complete, but I hope most of the less-obvious stuff is documented.

Get and build
https://github.com/frank256/lgui

Since this is developed for another project, there currently is no proper library distribution, I just import the code into my project, sharing some of the platform stuff. The API is still subject to change.

Build with CMake. I'm not much of an expert with that, but I've successfully built it with g++ and/or clang on Linux, macOS, and Windows.

Code sample
This is what the code looks like:

Todo

• proper touch support

• API stabilization / bugfixes

• build as a library

• skinned style

• undo for text input widgets

• more widgets (especially mobile-specific)

• animations

Comments, questions, feedback are appreciated.
Thank you for your attention.

Ah, interesting. The first thing I see in your header are the sub-widgets / children. That's exactly one of the things I have kept out of the base class.

The widget class has been very small at the beginning, but grown out of convenience. The number of methods far exceeds the number of data members, though, which I've been rather reluctant to add to. The methods could use better grouping; I've just moved things around a bit after breakfast.

I've seen your other thread about GUI core design, but cannot reply to it. lgui's documentation main page contains some stuff about lgui's design if you are interested. The docs are an extra target: make doc.

I'm SO tired of these 'I made a new C++ GUI'.

While you stick to C++ you forbid the vast majority of C users to use your library in their code.

On the opposite, making it in C would allow everyone to use it.

/EndOfPersonnalRant

Whatever, congrats on making something on your own.

This will not compile with gcc only. I said C, not a silly C++ to C wrapper :-^p

EDIT: Hello here BTW ^^

Let's see, what's the tally now?

TGUI - Trent Gamblin
ALGUI - axilmar
AGUI - jmasterx
LGUI - frank.n
EAGLE - Edgar Reynaldo
WidgetZ - SiegeLord

Who else have I forgotten?

The obligatory "why haven't we all been working on the same GUI for the last 10 years?" question is open.

I was (s)trolling through Online Users and I stumbled across this old gui thread of yours, which answers my question from above.

https://www.allegro.cc/forums/thread/613874

Sorry for derailing your thread with gui talk. xD

Java did it all wrong. A thousand different listener classes is just dumb. In my GUI, widgets emit events, as a WidgetMsg to a parent, as an EagleEventSource to an EagleEventListener, or as a derived class callback. I always felt signals and slots was intrusive and just plain bad design. So if a widget has children, its parents get the message and react accordingly, like if a scroll bar gets a message from one of its scroll button children, or from the scroller child. WidgetMessages also get queued to the top level gui, for later retrieval and processing. A generic event is also emitted, which any listener class (such as the EagleEventHandler, which is an event queue), can deal with. Beyond that, if you need to override something that happens to a widget such as an specific event like when text is entered or a mouse gets clicked, then you override the WidgetBase::PrivateHandleEvent function. You can intercept any and all events that the widget receives and totally change its behavior.

I never saw the need for drag and drop. And besides, in my GUI it could be easily implemented by making a top most widget that is invisible that monitors mouse clicks and the widgets underneath the mouse at the time, along with any dragging events and drop events. But none of my widgets support 'dropping' anything onto them, but they could do it easily with a virtual HandleDrop(WidgetBase* widget_dropped) function.

I don't know about that. I find that my layouts are pretty simple. Whenever you want to change the area of a widget, you call its SetWidgetArea function, which checks with its layout owner to see if it is an acceptable space to place the widget and returns the layout specified position for the widget. Any time the widget area is changed, a virtual member callback is executed, allowing you to reform your contents based on the new area. Widgets don't get to decide their actual position and dimensions, it's all handled by the layout. I suppose though, that a FlowLayout (which I haven't implemented yet) would need something like a preferred size to function properly. All my other layouts work great though. I have a dumb layout, a pin layout, a relative layout, a grid layout (which also works for the menu layout), splitter layouts, and I've experimented with animated layouts as well, which is really easy with my animation class. No more 3 column CSS Hell, where you can't get a damn table layout to work right ever. Table layout will be implemented, with variable size rows and columns, along with empty cells and spanning cells.

Really? You can't pick a shorter name than a 4 namespace deep constant? I just use enums, and they work fine.

Manually managing memory is one of the single greatest sources of bugs in code today. Memory leaks, dangling pointers, oh my! It's very simple to make your gui use shared pointers that can work for objects on the heap or the stack. Take for instance my "Eagle/SharedMemory.hpp" file :

https://github.com/EdgarReynaldo/EagleGUI/blob/core/include/Eagle/SharedMemory.hpp

It wraps a shared pointer and custom deleter so that stack and heap objects can be used together in a single object. Later on I have things like

typedef SHAREDOBJECT<WidgetBase> SHAREDWIDGET;

Which makes it an easily usable, easily copyable object that is safe to use for both stack and heap objects. No more worrying about memory. Less bugs FTW.

It's really not that much trouble to subclass a widget and override a single draw function or maybe two in case you need to handle events differently. I think external style classes are extranneous but I would need to look at your code to see what you're really doing. Mind pointing out a good example or where to look for the style code?

Ugh. I hate stretching my pinky_up_to_the_dang_underscore_key_all_the_time. It introduces typos. I follow a different convention. Named constants are uppercase generally if exposed. Classes and methods are CamelCase. Member variables are lower case, avoiding underscores if possible. No damn m_pHungarian junk I can't stand that it's not necessary and just makes code ugly and hard to type.

You need to create a cmake variable in your CMakeLists.txt and set it to some default directory to search for allegro. Then I can specify the directory in cmake-gui and then reconfigure the project to look for allegro there.

EDIT
Here are some libraries you probably DON'T want to use anymore : https://www.gamedev.net/blogs/entry/2256533-most-gui-libraries-are-terrible/

GWEN looked so promising from here : https://www.allegro.cc/forums/thread/608563/933616#target
but it's dead and gone without a trace.

Whoa, Edgar, man, he now sees he must have done it all wrong.

There are obviously different opinions about how to design a GUI...

How can it be intrusive that the callee does not even have to know about the caller? I can hardly think of anything less intrusive than the way lgui does signals and slots. You can just register any function to be called by a signal, it does not even have to know about the fact it is called by a signal, you do not have to use signals yourself - it is actually not intrusive at all.

You can do that even when you have styles. The idea behind styles is that you want to change the look completely rather than have to override every draw function. Usually, you want some consistency in the appearance. Plus, it keeps the inheritance hierarchy clean.

It is an enum, you can import it with using if need be, it is actually imported there, too, I think.

True. Well, I certainly do not mean to use new / delete manually all the time. I usually keep my widgets as member variables of classes that are ultimately created on the stack or in some container of an object residing on the stack. There are actually no "owning" pointers and almost no new / delete calls anywhere in my code, I think (I'd rather use make_unique). So no problems with that, plus I don't force anyone to use shared pointers: not intrusive.

I think there is middle ground between using C style pointers plus manual new/delete calls and using the bulldozer of wrapping everything in shared pointers. I don't like having no control plus I think it leads to bad code because you do not have to think about ownership anymore.

Shared pointers to objects on the stack? I don't think that is a good idea.

Now I doubt you were even serious. Drunk?

I took a look at GWEN, too (and an active fork called GWORK, I think), but found the code to be pretty unreadable.

How old are you?

Edit: Never mind.

Cheers, everyone.

Never mind. I thought you were trolling.

In fact, I have provided several examples of how to use the signals in this thread already:

lgui::TextField input;   
lgui::TextLabel output;
input.on_text_changed.connect([&output](const std::string& str) { output.set_text(str); });

Here, the label will mirror the text of the text field through connecting the TextField::set_text to the signal. In fact, the signal will call the provided lambda which could do whatever it pleases.

I usually have this as part of a class inheriting from lgui::BasicContainer or lgui::Container and capture this which automagically gives me access to every member variable.

There is also a convenience-overload of the connect-method which is passed a pointer-to-member-function and a reference to an object instance. So an alternative formulation would be this:

lgui::TextField input;   
lgui::TextLabel output;
input.on_text_changed.connect(&TextField::set_text, output);

The slots are just std::function (anything callable). The signals are usually public members prefixed with on_ and use the signal template. Declaring a signal looks like this:

lgui::Signal <const std::string&> on_text_changed;

The template parameters represent the signature of the functionals that can be connected. You can always connect functionals taking less parameters, but no functionals taking more parameters.

To emit a signal, the widget just calls on_text_changed.emit(text);

If you need the source of the call, you could use separate lambdas per source to also forward the source (or use std::bind). It would also be easy to extend the signal template to always forward a source reference. I had thought about doing that, but came to the impression that keeping it a one-way street (=simpler) would be better. Well, it's probably just not there because I haven't needed it so far.

Signal header can be found here:
https://github.com/frank256/lgui/blob/master/src/lgui/signal.h

It basically uses variadic templates and perfect forwarding. Most of the complexity comes from handling connecting and disconnecting to a signal even while the signal is being emitted. I've never actually used the stuff to disconnect individually, so maybe it will have to go in the future.

I know boost and I really don't like it.

Styles can be found here:
https://github.com/frank256/lgui/tree/master/src/lgui/style

It looks like an anonymous function that captures a reference to the output widget.
So when the signal triggers that function is executed and it pushes the captured output as an argument.

However,if output is allocated on the stack and it disappears then the reference points to garbage and things crash.

You could also capture output by value but in this situation that is not too helpful.

Yeah, they are declared individually per widget, the widget base class has none. Currently, it's usually just one per widget with one distinct signature each, mostly emitting one value only. They are intended for the semantically interesting stuff that is specific for the widget.

Right. That's the price to pay for the loose coupling. Mostly, widgets connected with each other are like siblings, ownership-wise, so they usually end up as members of the same class in my use cases. This makes the problem mostly a no-issue for me (I actually thought it was more problematic).

Another downside of the current approach is that signals cannot be overloaded (except that you can always choose to ignore parameters, i.e. you can always connect a functional taking no arguments even if the signal emitted many of them).

Exactly.

Yes. I'm not entirely satisfied with it, especially as every new widget added (to the lgui "core", that is) will introduce additional methods. Maybe I should have an abstract style class for each widget, with the style bundling them together and some generic method to get the appropriate style object instances. Or find some other useful abstraction over things to draw. But the original idea was to keep things simple, so I'll go with that existing solution for now.