Previously, this was used because we didn't have access to the current
view and `EventContext` was an element-only abstraction. Now that the
`EventContext` wraps the current view's `ViewContext` we can simply check
for the view's focus and avoid querying ancestors.
The editor is on the stack, so adding an item to the `Pane` containing
the editor will cause a double borrow and a consequent panic. This
commit fixes the issue by deferring the opening of the definitions.
During `layout`, we now pass a mutable reference to the element's
parent view. This is a recursive process that causes the view to
be removed from `AppContext` and then re-inserted back into it once
the layout is complete.
As such, querying parent views during `layout` does not work as such
views will have been removed from `AppContext` and not yet re-inserted
into it. This caused a bug in `KeystrokeLabel`, which used the `keystrokes_for_action`
method to query its ancestors to determine their type id and keymap context.
Now, any time a view notifies, we will cache its keymap context so that
we don't need to query the parent view during `layout`.
This is achieved by moving `available_actions` into `AsyncAppContext` (where
we know no view/window is on the stack) and `keystrokes_for_action` into `LayoutContext`
where we'll fetch the previous frame's ancestors and notify the current view if those
change after we perform a layout.
Focus is now one of the last things that happens during `flush_effects`,
and we shouldn't have relied on `defer` in the first place to verify
focus changes.
This was caused by accepting the call, which caused the notification to
be removed. When `active_call.accept_incoming()` finally completed, we
would try to get the app state from it in order to join the project, but
couldn't becuase the view would have already been dropped.
This commit fixes the bug by capturing a weak handle to the app state
when accepting the call as opposed to trying to read it from the view
when the accept completes.
Closes https://github.com/zed-industries/community/issues/1095
by forcing the non-Cancel button to get a focus.
Due to the way macOs handles buttons on modals, the focus gain had to be
achieved via certain button addition order, rather than conventional
"setFocus"-ish API, see the related comment for details.
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
