Now when you call spawn in various context, you pass an FnOnce that is called with an AsyncAppContext and returns a static future. This allows you to write async code similar to how our tests work, borrowing the guts of the AsyncAppContext when needed to interact, but using normal async await semantics instead of callbacks.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
The simplest solution I could come up with was to make quitting the app asynchronous. Calling mac::Platform::quit enqueues a request to quit the app and then allows the call stack to fully return. This ensures we aren't holding a borrow when we quit and invoke all the Window::on_close callbacks. Seems like it should be fine to be async on quitting.
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>
