https://www.allegro.cc/forums/thread/608404/932405#target

How should flow layouts work? I just implemented one in Eagle, that lays out widgets according to rows or columns first and by columns or rows second according to a widget's preferred size. Right now I set each widget to expand as much as possible once the row height is determined so it is completely taken up. This serves as a stackable hbox. I also made it possible to swap the major and minor axes of the flow so you can do vertical flows. Then I made it possible to anchor the flow at any corner of the widget's inner area.

Let's discuss GUIs here shall we? There are a million of them out there by now. I'm just hoping I can save some noobs some time with the writing of my library.

Should I have a separate hbox and vbox? It would be simple to subclass them and override a function maybe.

Also, handy tip of the day :
Look up Jump Tables and learn the power of a vtable. The cool thing about C++ is that you don't have to manually write vtables anymore.

The flow layout in agui is really simple,
It will layout the widgets from left to right and the tallest on that row is the starting point for the next row, but I added a few sugar things in there to sweeten it if you wanna look. https://github.com/jmasterx/Agui/blob/master/src/Agui/FlowLayout.cpp

A flow layout can be useful if you don't know the size at all, for example you have a picture gallery and then on a phone screen held upright there would be one item per row while on a desktop screen it would be 10 items per row.
I used one just recently, without you'd have to add some manual code to determine the number of columns based on sizes (which you may or may not know though) so it can get very complicated. Flow layout on the other hand is really simple, from that perspective

For lgui, I thought quite a lot about layouts. It's a bit difficult to get right because layout needs to adapt both top-down and bottom-up.
If the window size (the top widget) changes, widgets that depend on their parent's size need to be resized, potentially affecting every widget down to the leaves of the widget tree.
On the other hand, if e.g. a text changes such that a button or a label needs more space, it potentially affects every widget up to the top (or root) of the widget tree.
Because layout works in two ways like this, I found it's mandatory to have a two-pass layout process: the first pass is to measure (potentially) every widget top-down and returning and aggregating sizes back bottom-up. Only then can layout be executed in a second pass. If you try to do everything in one pass (i.e. adapting the parent's size when a child is added), there will be edge cases that are impossible to get right.
Then there are nasty special cases like scrollable areas which may provide unlimited space in one dimension, but not the other. So changes within a scrollable area might affect the surroundings, but it's not compulsory. And of course they have scroll bars which might (dis)appear, affecting the other dimension when the size of one dimension is changed. Also, there are things like word-wrapped text which can behave in nasty ways.

What I wanted in lgui is to have layout classes independent of the widgets (like Qt does). So there is a BasicContainer widget (and subclasses) which you can set layouts on, but the layout classes are a different hierarchy. You can also nest layouts without needing a widget container for each sub-layout. I'm not so sure whether this has been a good decision, since the code syncing the children of layouts and widgets is a bit difficult to understand. From a class design perspective, I still prefer this approach.

When I added basic animation (and transformation) support, I've also experimented with animating the layout changes , however, I'd still consider this experimental. There should be a test for that in the demo.

Soooo what I wanted to say is that IMHO the layout system itself needs to be quite robust.
Until now, I found lgui's VBoxLayout, HBoxLayout, RelativeLayout, SimpleTableLayout and FlowLayout sufficient. The FlowLayout just stacks widgets from top-to-bottom, left-to-right per default, also providing the options to solely operate vertically and horizontally. So, in a way, it's a more of a bottom-up kind of layout (the children determine the size), whereas H/VBoxLayout are (potentially) also top-down kind of layouts if configured with stretch factors. There's also a SortedFlowLayout providing the possibility to sort the children which arose from a special use case I had.
These are all quite simple layouts as my layout needs were fulfilled and I finally wanted to move on to other topics.

One thing with lgui's layout is that you need to pass an initial size for the top container (window). Of course you can query a minimum size hint for that, but you need to set it so that it is clear what space is considered available.

Another thing is that alignment provides a way to customize the usage of space assigned by the layout, so you have a widget within an invisible box in a way where it can be aligned right, centered or be stretched (interesting if layout operates in a top-down kind of way). Also, it serves the additional purpose to make it possible for the widget to greedily claim all space the layout offers.

Well, basically, the GUI needs some way to know where to distribute space. E.g. shall remaining space go between the buttons or shall the buttons grow to fit.
It's probably a case of providing sensible default behaviors. E.g. in lgui, if the button is asked how wide it wants to be given an available width, it restricts itself to the width actually needed (IIRC). If you want different behavior, you may be able to force it with an alignment setting (or using a different layout).

I don't do enough of that. I would do much better to hold off coding until I grok in fullness. That doesn't mean you can't do some exploratory coding to test an idea, it just means you're not trying to produce the finished version by starting with "main.c" like so many wannebe Quake clone makers.

How is your progress, Edgar?