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.
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.
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>
I don't actually think it was correct to allow the future to borrow a mutable app reference. I went back to passing a wrapper around the refcell to async tests. They'll be a bit more annoying to write but also totally safe.
