Call on_focus on the root view when the window is originally created. Test dropping a focused view. Simplify test to avoid relying on emitting events.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
This allows us to spawn long-running tasks without leaking entities, but it also ensures that if we *do* hold on to a task, that the entity exists until the future or stream complete so that the task doesn't need to return an Option type.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
This way, if we create and drop a handle during the creation of a view, we don't drop the view before we have a chance to increment its initial reference count.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
Instead, store all views in a single top-level map that's keyed by window id and view id. This ensures we'll keep a view alive even if its window is gone, so long as we're holding a handle. This can happen with things like spawned tasks. We don't want to panic during a spawned task after we close the window.
I didn't realize a previous change had broken stuff. We need to always call `remove_dropped_entities` and `update_windows` in `flush_effects`, even if there aren't any effects. To achieve this, I use a `loop` to ensure we call these methods at least once before breaking.
This ensures that we correctly update the hover state of elements whose position has changed relative to the mouse cursor even though the mouse hasn't actually moved.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
It returns a future that resolves when the provided predicate returns true. The predicate is called any time the handle's targeted entity calls notify.
Still need to add a timeout and completely remove finsih_pending_tasks.
* Enforce a min width per tab
* Center the title within tab, regardless of icon
* Render icon over the top of the tab title
* Ensure there is always a fixed minimum amount of filler to the right of all tabs
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
The easy-parallel crate spawned new threads on each call, which was resulting in way too many threads.
Co-Authored-By: Brooks Swinnerton <934497+bswinnerton@users.noreply.github.com>
Previously we would dispatch the same global action more than once
because we would invoke `dispatch_action_any` _and_
`dispatch_global_action_any`. However, the former already takes care of
going through the global action handlers when no entity in the dispatch
path handled the action.
Max Brunsfeld