bevyengine
Rename `UiRect` to `Frame`
Objective
UiRect is confusingly named (nothing it represents is a rectangle) and we have a consensus (as far as I can tell) that Frame is the best alternative.
If Frame seems ambiguous (not so much internally but with concepts from foreign UI apis), UiFrame could also be okay.
Alternative proposal: #7710
Changelog
UiRectis renamed toFrame
Migration Guide
UiRect has been renamed to Frame.
It looks like your PR is a breaking change, but you didn't provide a migration guide.
Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Not sure about Frame seems like it'd be confused with the frame as in frames per second. I don't think UiFrame fixes the issue either.
Not sure about
Frameseems like it'd be confused with the frame as in frames per second. I don't thinkUiFramefixes the issue either.
I can see what you mean, but won't it be obvious from the context that it means a geometric frame?
Cart's previously stated that "Bevy is treated as a global namespace", which I think that Frame runs a bit close to violating. I still think it's a much better name than UiRect. LayoutFrame would also be fine by me, but I'm increasingly leaning towards distinct types for margin/padding/border.
Cart's previously stated that "Bevy is treated as a global namespace", which I think that
Frameruns a bit close to violating. I still think it's a much better name thanUiRect.LayoutFramewould also be fine by me, but I'm increasingly leaning towards distinct types for margin/padding/border.
Yeah I can see that in a global namespace Frame intuitively feels like it would be a type associated with animation and, although it might be workable now to have only one type, as taffy adds more features the margin, border, and padding interfaces will probably diverge even further making distinct types more desirable.
I thought this would be an easily accepted non-controversial obvious improvement but I've come around to agreeing with hymm now.
@alice-i-cecile
Do you think we should close this one, and just concentrate on #7710 (or an incremental step towards it, maybe just a separate Margin type to start with)?
Thinking on it, maybe #7710 and #7569 don't make sense as distinct PRs and should be combined.