Track sizing support in Grid widget and view

[RagibHasin]

This completely reworks how the Grid widget lays its children out.

The new implementation closely follows CSS grid specification with one intentional deviation, it does not support minmax track size. It has been omitted from track sizing MVP and because I don't find it very useful.

[PoignardAzur]

Thanks for the work! Not sure I'll have time to review it in the coming weeks, but I definitely appreciate changes that get us closer to CSS Grid behavior.

At first glance, my impression is that this PR makes a lot of drive-by changes to the API, some of which I don't agree with. For instance, I don't see a reason to remove GridExt::grid_pos, and I think replacing GridParams::new with tuples makes the code harder to read.

Anyway, I'll do a more in-depth review soon. This is work we really want to get merged!

[RagibHasin]

I don't see a reason to remove GridExt::grid_pos

I removed that and unified its functionality into GridExt::grid to be similar to FlexExt::flex. Also, GridParams implements From<(u16, u16)> for position items, making grid_pos more verbose.

I think replacing GridParams::new with tuples makes the code harder to read.

I would replace the tuples with GridParams builder methods if requested. GridParams::new() is now a default constructor as it should be, IMO.

[PoignardAzur]

(I'm back from RustWeek, will probably review this tomorrow!)

[PoignardAzur]

Some general thoughts:

• I maintain that the impl From<...> with tuples are a bad idea. They're way more error-prone than the builder methods, they're less IDE-friendly (IDEs can show you function argument names, but not for tuples), they're less explicit for someone reading the code, etc. Unless there's a very strong argument to have them (other than "it makes code shorter") I think I'll block the feature until they're removed, sorry.
• I think you should keep the Grid::with_dimensions builder, since I expect it to be useful for a lot of examples. You could rename it and/or document that it creates tracks with GridTrackSize::FRACTION, or even pass the track size as a parameter.
• Overall, I think it would be helpful to split this PR in two, one that deals with the renamed constructors, then one that deals with the logic changes. I won't block on it though.

Sorry to wait so long just to add more negative feedback. I still need to review the grid code itself, but I do think the ergonomics part is important on its own.

[RagibHasin]

• I maintain that the impl From<...> with tuples are a bad idea. They're way more error-prone than the builder methods, they're less IDE-friendly (IDEs can show you function argument names, but not for tuples), they're less explicit for someone reading the code, etc. Unless there's a very strong argument to have them (other than "it makes code shorter") I think I'll block the feature until they're removed, sorry.

My rationale for this was similar impls for FlexParams. I agree that the lack of parameter name hints would hinder unfamiliar users. Also, the From impls feel very much like a DSL.

But I don't like the impending verbosity of the builder patterns, too. 🤷🏽

I think if we revert to GridExt::grid_pos with (x: impl Into<Option<u16>>, ..) as parameters, we can avoid most of the verbosity. Would the impl Into<Option<u16>> tank compile times heavily?

• I think you should keep the Grid::with_dimensions builder, since I expect it to be useful for a lot of examples. You could rename it and/or document that it creates tracks with GridTrackSize::FRACTION, or even pass the track size as a parameter.

I have no opinion in this regard, so I would re-establish Grid::with_dimensions.

• Overall, I think it would be helpful to split this PR in two, one that deals with the renamed constructors, then one that deals with the logic changes. I won't block on it though.

That would be painful. I would like to skip splitting it.

[PoignardAzur]

I think if we revert to GridExt::grid_pos with (x: impl Into<Option>, ..) as parameters, we can avoid most of the verbosity. Would the impl Into<Option> tank compile times heavily?

I think the compile times would be fine, but also I think that's over-engineering. In most cases I expect users to either specify both coordinates or nothing. grid_pos(u16, u16) should be fine.

That would be painful. I would like to skip splitting it.

Fair enough.