We now always have a RenderContext when rendering MouseEventHandlers or scrollable Flex columns/rows.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
If for some reason the handle got dropped and we call it, we'll deal with it somewhat gracefully.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
In some cases, we need to render during layout. Previously, we were rendering with a LayoutContext in some cases, but this commit adds the ability to retrieve a render context with a given handle and we use that feature in UniformList.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
This can be used to lookup keystrokes that will dispatch an action based on the currently focused view. There might be multiple, but we return the first found, meaning the most recently added bindings matching that action for the closest view to the focused view in the hierarchy.
This ensures that the only strong reference to the presenter is held
by `App`. This is important because we want to call `flush_effects`
when removing a window and implicit drops of the `Presenter` would
make that hard.
Before this commit, if a rendered view contained strong handles to
views and models, we would only drop them on the next `flush_effects`.
This was manifesting itself in `Project`s not being released when
closing their containing window.
Previously, we were mutating the remaining space stored on the layout
state, which would cause re-paints to always have a `remaining_space`
of 0 and therefore not align `flex_float` elements to the right/bottom.
Previously, when an atlas was emptied, we would move it into a different
vector: free_atlases. This removal could cause existing atlas ids to
refer to the wrong atlases.
We updated the core-foundation crates because Tonic (the GRPC crate) relies on a newer version of core foundation to find TLS root certificates.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
We now run tests that interact with the real database under a Tokio reactor. We make the tests run multi-threaded so we can block on the main thread on database teardown and still make progress actually tearing down the DB.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
