You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rows and columns are used more than any other component, and often don't have any style properties other than direction, so this would save a lot of typing.
I think it would also make the structure of the UI easier to visualise from the code if the direction was a bit more prominent rather than buried in a property. Compare:
The one notable argument against Row/Column classes is that it merges style with content - in principle, with a full CSS engine, it should be possible to take a single composition of boxes, and turn it into a near arbitrary layout.
There's also the question of what happens when someone writes toga.Column(style=Pack(direction="row"), children=...).
However, pragmatically, we don't have a full CSS engine yet; and most users aren't thinking about their app from a "full separation" lens, so I guess including Row/Column as a feature, and documenting the "problems for advanced users" is a reasonable compromise.
Merging style with content is indeed what I was proposing in #3011. In that model, Column and Row would override the direction property to make it read-only, so toga.Column(style=Pack(direction="row")) would cause an immediate exception.
Alternatively, I guess Column and Row could just be shorthand for "Box with a default direction" rather than full subclasses.
Let's first decide how to proceed in #3011, and then come back to this.
Rows and columns are used more than any other component, and often don't have any style properties other than
direction
, so this would save a lot of typing.I think it would also make the structure of the UI easier to visualise from the code if the direction was a bit more prominent rather than buried in a property. Compare:
with:
The text was updated successfully, but these errors were encountered: