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>
We still aren't handling CLI requests in the app, but this lays the foundation for bi-directional communication.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
This allows us to focus the query editor of the project search when deploying it. Previously, a complex interplay between focus events was preventing this from working in an intuitive way. What happened previously:
- We'd activate the project search, which enqueued a focus effect for the project search view
- We'd focus the query editor, which enqueued an effect
- We'd process the focus effect for the search view, which would enqueue an effect to transfer focus to the results editor
- We'd process the effect to focus the query editor
- We'd process the effect to focus the results editor
Now...
- We activate the project search pane item, enqueuing a focus effect for the project search itself
- We focus the query editor and *remove* the previous pending focus change effect
- We process the focus effect
Also, allow arbitrary types to be used as Actions via the impl_actions macro
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Keith Simmons <keith@zed.dev>
This is in contrast to not dispatching the event altogether in `Flex` when
the event is not contained in the flex element bounds. That approach was
problematic because it didn't give an opportunity to `MouseEventHandler`s
to handle mouse move events when they didn't intersect with the element bounds,
causing elements to never clear their hover state, cursor style, etc.
This adds the ability to make a Flex element scrollable by passing a type tag and instance id, which we use to store the scroll position in an ElementStateHandle.
Still need to allow the element to auto-scroll.
Previously, we weren't updating the toolbar's active item when emptying out a pane. This enhances an integration test to ensure that we don't hold references to any editors or buffers once we close everything.
Instead, derive it from the presenter. This makes tests easier to write and more reliable since we'll be accurately simulating the actual relationship between parent and child views.
We still have issues with project search styling.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
This should resolve some rendering artifacts potentially caused by
floating point errors when sampling the texture. It should also lead
to crisper images when icons are rendered midway through a pixel.
Also: Make some structural adjustments to remove the need for defer. Instead of accessing the global in associated VimState functions, have a single method that allows us to call update instance methods.
This also changes the structure of the follow state back to be per-pane. This
is because we can't share the same view state across different panes for
a couple of reasons:
- Rendering the same view in N different panes is almost always not something
that we want due to global state such as focus.
- If we allowed it and a user followed the same person in two different panes,
there would be no way of unfollowing in one pane without also unfollowing in
the other.
