Add an enum with only the numeric variants of Val

[ickshonpe]

Problem

The Style properties padding and border can be assigned values of Val::Auto or Val::Undefined when only the numeric variants make sense. There isn't a sensible way for the UI to determine these values automatically, except to just set them to zero.

Solution

• Add a second enum Breadth with only the evaluatable variants of Val.
• Make UiRect generic.
• Change the types of Style's padding and border fields to UiRect<Breadth>.

I'm not sure I like the name Breadth, but it's shorter than Thickness and seems more descriptive than Length.

Another option would be to rename Val to AutoVal and rename Breadth to Val. AutoVal would be used a lot more though, so this might be annoying.

Perhaps NumVal or EVal for Evaluatable Value. Num would be nice but ambiguous with a lot of other things.

There might be objections to making UiRect generic. Could be divided into NumRect and AutoRect or something instead. Don't care either way, or about any of the namings.

---

Changelog

• Added an enum Breadth, that is similar to Val but without Val's non-numeric variants.
• Changed UiRect into a generic struct.
• Changed the types of the padding and border fields of Style to UiRect<Breadth>.
• Made the minimum necessary changes to the affected examples.

Migration Guide

• UiRect is now a generic struct with a type parameter, which is Val by default.

• A new enum Breadth has been added which is similar to Val but without Val's non-numeric variants Val::Auto and Val::Undefined.

• The padding and border fields of Style have been changed to type UiRect<Breadth>. Any padding and border values of Val::Auto or Val::Undefined should be replaced with Breadth::Px(0.), which is the default value for Breadth.

[alice-i-cecile]

I definitely like this direction. Unusable values should be unrepresentable. Great implementations with nice error types!

Labelling this with controversial, since this is a major use-facing UX change.

[nicoburns]

This seems like a reasonable change to introduce (although IMO it does add friction when authoring styles as you have to remember which properties correspond to which types). I'm not keen on the name though. Perhaps FixedVal could be an alternative name.

[ickshonpe]

This seems like a reasonable change to introduce (although IMO it does add friction when authoring styles as you have to remember which properties correspond to which types). I'm not keen on the name though. Perhaps FixedVal could be an alternative name.

I think if we went that way, using Val for the numerical values and renaming Val to AutoVal would make the most intuitive sense.

And then we could implement From<Val> for AutoVal, and have the current constructor functions take an Into<AutoVal> so that most existing code using Bevy UI wouldn't need any changes.

[alice-i-cecile]

I think if we went that way, using Val for the numerical values and renaming Val to AutoVal would make the most intuitive sense.

I like this better than FixedVal, and I think better than the current proposal.