The idea of the grid flow layout share some aspects with our column flow one, and the spreadsheet concept.
You can fill it with sub-items either column by column, or row by row.
You can enforce a specific number of columns, use purely auto-computed one (based on available width), or auto-compute number of columns multiple of specified value.
Columns and rows can be even, or adapt to needed space by their sub-items.
Unlike column flow, there is always only one item per row and column (per cell).
The auto-compute of columns number tries to be smart and 'fill' its rows and columns as best as possible. E.g. if you have a row-major gridflow layout with four items, it will never go to a three-columns layout (because 4 items fill better either 2×2, 4×1 or 1×4 grids).
Only piece of code to review here (if you feel like doing so ;) ) is the UILayoutGridFlow related one.
This patch also has some py ui script tweaks, and some hacks in UI code, done for experimental purpose and discussion/proposal, those are by no mean intended to be committed, quite obviously.
I started working on this layout with the idea of getting something usable in panels to e.g. display sets of images or other assets. Ideally, I ’d also like to use it to replace manual drawing of entries in file browser or UIList (especially the grid case), but there are more issues to solve here first (we need to get auto-computed grid size back from the layout engine, to handle amount of items to draw, scrolling, etc.).
Also, found on the way it could be an interesting solution for 'resize layout' issue (e.g. with panels, often large ones waste a lot of space, while narrow ones become unusable), so did very quick experiment with Influence panel of textures (very easy case of course, gif, click to see animation):
Main issue here currently is that UI code reports fixed huge 'ideal' dimension for its buttons in many, many case, instead of checking their actual required width. Not sure why, this needs more investigation.