beeware
Grid layout
What is the problem or limitation you are having?
The Pack layout is nice, but sometimes you want a table-like layout.
A good example is a form, with labels on the left and input widgets on the right. The labels should only take as much space as they require, and the input widgets should be left aligned.
Describe the solution you'd like
A Grid widget that resembles the CSS Grid specification.
This will mean adapting the pack algorithm.
Describe alternatives you've considered
-
A simpler Grid that does not try to follow the CSS Grid spec. Something that just lays out widgets in rows and columns, with colspans or rowspans. This would probably already cover most use cases.
-
A separate Grid layout from Pack (e.g. specified in a widget as
style=Grid(...). This would avoid further complexity in the pack algorithm. But a refactoring of pack.py would probably be required to maximise code reuse.
Additional context
No response
I don't deny the use case; grids are very handy for layout purposes.
I have a mild hesitation to support adding this to Toga's builtin layout, because it would draw development effort away from Colosseum, which is what I consider the "end game" for Toga's layout. That said - Pack exists because Colosseum was taking too long to develop, and in all honesty, it's not seeming likely it will get significant attention any time soon. So - pragmatically, I can see how adding support for a CSS3-grid subset, akin to how Pack is (currently) a CSS3-flexbox subset, could be a workable middle ground.
Regarding implementation, my gut reaction is that I don't think the answer is a completely standalone "Grid()" style object. I think grid is just another option on display - it's currently pack or none; grid would be another option. That's because you can put a pack layout inside a grid layout, and my immediate impression is that it would be difficult (if not impossible) to completely separate the two. That said, I also haven't looked into the problem in depth, so I'd be happy to be proven wrong if a split implementation is workable.
If someone wants to take a look at this problem: Step 1 will be proposing a workable CSS3-grid subset, with a mapping to strict CSS3 that can be used for reference purposes. Having a defined mapping to "pure" CSS3 is an important part of the process - firstly, for debugging purposes, but also for platforms like Web that only have CSS-based rendering options.
The CSS grid layout is quite complicated, but it does cover all the common use cases:
-
The grid can either have a fixed number of columns and rows, or determine them automatically from its content.
-
Child elements take up one cell by default, but can also span multiple rows and columns. They may be laid out automaticaly from left to right and then top to bottom like text in a paragraph, each one being placed in the first location where it doesn't overlap any of its predecessors. Or they can be positioned with manual X and Y coordinates, which allows chidren to overlap.
A option that is related (although the connection may not be obvious) is #3192 - a Forms API. A Form is one of the most common use cases for a grid layout - a 2xN layout of labels and widgets. Having a Form API won't remove the need for a Grid layout, but it might take off some immediate pressure.