This expansion only triggers if the root widget measures larger than the
window's current size. We can't set a minimum size explicitly unless a
Resize widget is present, as we don't have enough knowledge to ensure
that the exact measurement we received was indeed the smallest layout in
any given direction. We only know that given the current constraints,
the returned measurement was the smallest possible. All future queries
will have to still be done again, as any change to the constraints could
impact the measured size.
Closes#60
Stepping in sliders is a compromise due to the flexibility of the
current slider implementation. I don't want to force types to implement
Add, and I don't like forcing types to require a Step (ie, what's the
appropriate value for f32 to specify as its next value?). Using a
percentage combined with lerp keeps the implementation fairly
straightfoward, although I remember experiencing this type of
configuration in another UI framework a long time ago and thinking it
was a little annoying to work with.
Ultimately, setting actual step boundaries can be done by customizing
the type that the slider is operating over. I feel like that's a much
more powerful design than I've experienced in previous frameworks, so
I'm hoping this percent step behavior is a reasonable compromise.
Inset outlines may not be the right approach, but it simplifies
potential alignment issues caused by insetting all filled background
drawing by half the width of the focus ring.
After trying to run Gooey again on my Mac for the first time in a few
weeks, I found that I ran into the Condvar issue again. Rather than
pasting AssertUnwindSafe in those files, I've both reported the
discrepency in unwind safety (rust-lang/rust#118009) and moved the
workaround into a type that only uses AssertUnwindsafe when compiling
for Apple.
