Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't create event loop ondemand #2431

Closed
emilk opened this issue Aug 15, 2022 · 13 comments · Fixed by #2767
Closed

Can't create event loop ondemand #2431

emilk opened this issue Aug 15, 2022 · 13 comments · Fixed by #2767
Labels
DS - macos H - help wanted Someone please save us

Comments

@emilk
Copy link
Contributor

emilk commented Aug 15, 2022

I want to be able to open a window, use event_loop.run_return to process some events on it, then close it, and then later open another window. When I try this on my Mac, I find that the second time I run run_return I get Event::LoopDestroyed almost immediately, and the new window is destroyed. This is the code I'm running:

fn main() {
    use winit::{
        event::{Event, WindowEvent},
        event_loop::EventLoop,
        platform::run_return::EventLoopExtRunReturn,
        window::WindowBuilder,
    };

    fn show_window(event_loop: &mut EventLoop<()>, window_name: &str) {
        eprintln!("Creating window {:?}", window_name);

        let window = WindowBuilder::new()
            .with_title(window_name)
            .build(event_loop)
            .unwrap();

        event_loop.run_return(|event, _, control_flow| {
            control_flow.set_wait();

            match event {
                Event::LoopDestroyed => {
                    eprintln!("Event::LoopDestroyed.");
                }

                // Platform-dependent event handlers to workaround a winit bug
                // See: https://github.com/rust-windowing/winit/issues/987
                // See: https://github.com/rust-windowing/winit/issues/1619
                Event::RedrawEventsCleared if cfg!(windows) => {
                    println!("rendering");
                }
                Event::RedrawRequested(_) if !cfg!(windows) => {
                    println!("rendering");
                }

                Event::WindowEvent { window_id, .. } if window_id != window.id() => {
                    // This can happen if we close a window, and then reopen a new one,
                    // or if we have multiple windows open.
                    eprintln!("Ignoring event to old window");
                }
                Event::WindowEvent {
                    event: WindowEvent::CloseRequested,
                    ..
                } => {
                    eprintln!("WindowEvent::CloseRequested");
                    control_flow.set_exit();
                }
                Event::WindowEvent {
                    event: WindowEvent::Destroyed,
                    ..
                } => {
                    eprintln!("WindowEvent::Destroyed");
                    control_flow.set_exit();
                }
                _ => (),
            }
        });

        eprintln!("-----------------");
    }

    let mut event_loop = EventLoop::new();
    show_window(&mut event_loop, "First Window");
    show_window(&mut event_loop, "Second Window");
}

And this is the output:

Creating window "First Window"
rendering
rendering
WindowEvent::CloseRequested
Event::LoopDestroyed.
-----------------
Creating window "Second Window"
rendering
rendering
Event::LoopDestroyed.
-----------------

The WindowEvent::CloseRequested is me closing the window, but the second window also closes without any reason.

According to @zu1k, this is also a problem on Windows, but there it can be fixed by adding the following code after the first run_return:

    event_loop.run_return(|_, _, control_flow| {
        control_flow.set_exit();
    });

Related issue: emilk/egui#1919


One very bad work-around is to calli run_return multiple times, like so:

        let mut quit = false;
        while !quit {
            event_loop.run_return(|event, _, control_flow| {
                // Only set `quit = true;` when we really want to close the window.
            });
        }

This still spams Event::LoopDestroyed over and over again, but the window stays up. However, it uses up ALL the CPU of one core, so this is NOT a viable solution.

@kchibisov
Copy link
Member

Not sure how I've missed that issue.

You're might not be familiar with such concept, but event loop is a connection to the display server in the first place, dropping it will drop all the windows present, it's more of an exception on macOS, it's not possible at all on X11/Wayland.

I think that LoopDestroyed is confusing event, the loop is not destroyed with run_return at all, it's alive, it's just not polling the events.

One very bad work-around is to calli run_return multiple times, like so:

It seems like what you want is to run winit's event loop along side some other event loop and not handle everything inside the run``run_return closure. Such use case is sort of common when it comes to polling, from what I can tell.

There's an example how to do block_on https://github.com/notgull/winit-block-on. In your case I'd assume you could simply set the value inside the run_return and Wait in it initially.

This still spams Event::LoopDestroyed over and over again, but the window stays up. However, it uses up ALL the CPU of one core, so this is NOT a viable solution.

It'll be a solution if you Wait and exit on some condition you set from the run_return.

The issue right now is that you're not notified for winit's event loop readiness.

So, to sum up, what you want is not possibly theoretically, but it's likely not what you actually need anyway. There's no solution on putting winit's loop inside your epoll, and I doubt there will be a good way to do this... The alternative solution to register inside winit's epoll, which is more of a realistic, once the macOS/Windows will be sorted.

Maybe approach with async and block_on will work for you though.

@kchibisov
Copy link
Member

The issue title is also misleading.

@kchibisov kchibisov changed the title Can't call run_return more than once on Mac Can't create event loop ondemand Mar 6, 2023
@kchibisov kchibisov closed this as not planned Won't fix, can't repro, duplicate, stale Mar 6, 2023
@rib
Copy link
Contributor

rib commented Mar 6, 2023

One very bad work-around is to calli run_return multiple times, like so:

It seems like what you want is to run winit's event loop along side some other event loop and not handle everything inside the runrun_return `` closure. Such use case is sort of common when it comes to polling, from what I can tell.

I think this is describing what the work-around is doing, not what the original intent seems to be.

E.g. see here for added context for this issue: emilk/egui#1889 (based on other issues that @emilk has linked here)

I think for the use case behind this issue @emilk would have been happy for all the event handling to be done inside run_return.

@kchibisov I think you discovered this issue after I linked it to this issue #2706 (comment) and I did that in part because this was an example of a use case that didn't want to move handling of events outside of winit. This issue looks like its about being able to run a temporary (but self-contained) event loop.

I think the use case here is being able to have some application (hypothetically could be a command line app, not based on a mainloop) that shows a temporary pop-up UI, e.g. to show stats.

I think for this use case the run_return was expected to be self-contained and behave more-or-less like run except for the fact that the event loop could exit after the temporary UI has been closed, and potentially run again in the future.

For this use case it's potentially fine that it will completely close any display connections etc when the loop exits because the loop will only exit after the temporary UI has been closed.

So I don't think there was any expectation here that run_return was going to return while leaving windows / UI intact, it's just the "bad work-around" that relies on this.

@rib
Copy link
Contributor

rib commented Mar 6, 2023

I think maybe it could be fair to re-open this issue while it looks like the reason for closing it was more based on how the workaround works, not so much about the original issue.

The response above looks like it's more applicable to #2706 than here, since the code in #2706 really is explicitly trying to embed Winit event polling into an outer loop.

@kchibisov
Copy link
Member

I think maybe it could be fair to re-open this issue while it looks like the reason for closing it was more based on how the workaround works, not so much about the original issue.

I think I've clearly stated why it doesn't applicable? Dropping event loop will drop connection to display server, dropping all the windows along the way. I'm pretty sure you're aware what happens when you close connection to x11/wayland server? I'm not entirely sure wrt X11, but with Wayland everything will die.

So it's not possible, we don't even allow creating multiple event loops now anyway.

@rib
Copy link
Contributor

rib commented Mar 6, 2023

I think I've clearly stated why it doesn't applicable? Dropping event loop will drop connection to display server, dropping all the windows along the way. I'm pretty sure you're aware what happens when you close connection to x11/wayland server? I'm not entirely sure wrt X11, but with Wayland everything will die.

yeah, but for this use case I think that's ok. It's sort of like you're responding to the problems with #2706 here.

I think here the event loop is only intended to exit after the windows for the temporary UI have been closed, so there won't be any windows to preserve and it's fine that the display connection is dropped.

@kchibisov
Copy link
Member

Oh, I seems like misread the issue example slightly, indeed looks like a macOS issue. You should be able to open window, do things with it, drop, and open again latter on with different run_return invocation.

@kchibisov kchibisov reopened this Mar 6, 2023
@kchibisov
Copy link
Member

kchibisov commented Mar 6, 2023

@emilk could you try to drop window from inside the event loop and see if it changes anything or if the latest winit has this issue in the first place? I think on macOS and some other platforms you need event loop running for things to work properly.

@emilk
Copy link
Contributor Author

emilk commented Mar 11, 2023

Trying the original code on latest master (b18295a) I get similar results:

Creating window "First Window"
rendering
rendering
WindowEvent::CloseRequested
Event::LoopDestroyed.
-----------------
Creating window "Second Window"
rendering
Ignoring event to old window
rendering
Event::LoopDestroyed.
-----------------

I've tried dropping the Window from inside the event loop like so:

fn main() {
    use winit::{
        event::{Event, WindowEvent},
        event_loop::EventLoop,
        platform::run_return::EventLoopExtRunReturn,
        window::WindowBuilder,
    };

    fn show_window(event_loop: &mut EventLoop<()>, window_name: &str) {
        eprintln!("Creating window {:?}", window_name);

        let window = WindowBuilder::new()
            .with_title(window_name)
            .build(event_loop)
            .unwrap();
        let our_window_id = window.id();
        let mut window = Some(window);

        event_loop.run_return(|event, _, control_flow| {
            control_flow.set_wait();

            match event {
                Event::LoopDestroyed => {
                    eprintln!("Event::LoopDestroyed.");
                    window = None;
                }

                // Platform-dependent event handlers to workaround a winit bug
                // See: https://github.com/rust-windowing/winit/issues/987
                // See: https://github.com/rust-windowing/winit/issues/1619
                Event::RedrawEventsCleared if cfg!(windows) => {
                    println!("rendering");
                }
                Event::RedrawRequested(_) if !cfg!(windows) => {
                    println!("rendering");
                }

                Event::WindowEvent { window_id, .. } if window_id != our_window_id => {
                    // This can happen if we close a window, and then reopen a new one,
                    // or if we have multiple windows open.
                    eprintln!("Ignoring event to old window");
                }
                Event::WindowEvent {
                    event: WindowEvent::CloseRequested,
                    ..
                } => {
                    eprintln!("WindowEvent::CloseRequested");
                    window = None;
                    control_flow.set_exit();
                }
                Event::WindowEvent {
                    event: WindowEvent::Destroyed,
                    ..
                } => {
                    eprintln!("WindowEvent::Destroyed");
                    window = None;
                    control_flow.set_exit();
                }
                _ => (),
            }
        });

        eprintln!("-----------------");
    }

    let mut event_loop = EventLoop::new();
    show_window(&mut event_loop, "First Window");
    show_window(&mut event_loop, "Second Window");
}

But the result is still the same - I only get one window, and the output is still

Creating window "First Window"
rendering
rendering
WindowEvent::CloseRequested
Event::LoopDestroyed.
-----------------
Creating window "Second Window"
rendering
Ignoring event to old window
rendering
Event::LoopDestroyed.
-----------------

Turning on some TRACE logging I get:

Creating window "First Window"
TRACE [winit::platform_impl::platform::window] Triggered `WinitWindow::new`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `frameDidChange:`
TRACE [winit::platform_impl::platform::view] Completed `frameDidChange:`
TRACE [winit::platform_impl::platform::view] Triggered `viewDidMoveToWindow`
TRACE [winit::platform_impl::platform::view] Completed `viewDidMoveToWindow`
TRACE [winit::platform_impl::platform::window] Locked shared state in `WinitWindow::new`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `WinitWindow::new`
TRACE [winit::platform_impl::platform::window] Locked shared state in `set_fullscreen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `set_fullscreen`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::view] Triggered `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Completed `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Triggered `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Completed `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `WinitWindow::new`
TRACE [winit::platform_impl::platform::view] Triggered `drawRect:`
rendering
TRACE [winit::platform_impl::platform::view] Completed `drawRect:`
TRACE [winit::platform_impl::platform::app_delegate] Triggered `applicationDidFinishLaunching:`
TRACE [winit::platform_impl::platform::app_state] Activating visible window
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::app_delegate] Completed `applicationDidFinishLaunching:`
rendering
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowDidChangeOcclusionState:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowDidChangeOcclusionState:`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowDidBecomeKey:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowDidBecomeKey:`
TRACE [winit::platform_impl::platform::view] Triggered `resetCursorRects`
TRACE [winit::platform_impl::platform::view] Completed `resetCursorRects`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowDidChangeScreen:`
TRACE [winit::platform_impl::platform::window] Locked shared state in `window_did_change_screen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `window_did_change_screen`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowDidChangeScreen:`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowShouldClose:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowShouldClose:`
WindowEvent::CloseRequested
TRACE [winit::platform_impl::platform::window] Locked shared state in `fullscreen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `fullscreen`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowWillClose:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowWillClose:`
Event::LoopDestroyed.
-----------------
Creating window "Second Window"
TRACE [winit::platform_impl::platform::window] Triggered `WinitWindow::new`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `frameDidChange:`
TRACE [winit::platform_impl::platform::view] Completed `frameDidChange:`
TRACE [winit::platform_impl::platform::view] Triggered `viewDidMoveToWindow`
TRACE [winit::platform_impl::platform::view] Completed `viewDidMoveToWindow`
TRACE [winit::platform_impl::platform::window] Locked shared state in `WinitWindow::new`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `WinitWindow::new`
TRACE [winit::platform_impl::platform::window] Locked shared state in `set_fullscreen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `set_fullscreen`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowDidBecomeKey:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowDidBecomeKey:`
TRACE [winit::platform_impl::platform::view] Triggered `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Completed `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Triggered `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Completed `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `WinitWindow::new`
TRACE [winit::platform_impl::platform::view] Triggered `resetCursorRects`
TRACE [winit::platform_impl::platform::view] Completed `resetCursorRects`
TRACE [winit::platform_impl::platform::view] Triggered `drawRect:`
rendering
TRACE [winit::platform_impl::platform::view] Completed `drawRect:`
Ignoring event to old window
rendering
Event::LoopDestroyed.
TRACE [winit::platform_impl::platform::window] Locked shared state in `fullscreen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `fullscreen`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowWillClose:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowWillClose:`
-----------------

@kchibisov
Copy link
Member

kchibisov commented Mar 11, 2023

What if you create event loop each time for a new window, will it work?

So you'd create and then drop the loop with the window right away.

Though, I have a feeling that you'll be restricted right now to do so, might require patching the check inside winit preventing the multi-loop.

@emilk
Copy link
Contributor Author

emilk commented Mar 11, 2023

With

--- a/src/event_loop.rs
+++ b/src/event_loop.rs
@@ -112,9 +112,9 @@ impl<T> EventLoopBuilder<T> {
     #[inline]
     pub fn build(&mut self) -> EventLoop<T> {
         static EVENT_LOOP_CREATED: OnceCell<()> = OnceCell::new();
-        if EVENT_LOOP_CREATED.set(()).is_err() {
-            panic!("Creating EventLoop multiple times is not supported.");
-        }
+        // if EVENT_LOOP_CREATED.set(()).is_err() {
+        //     panic!("Creating EventLoop multiple times is not supported.");
+        // }
         // Certain platforms accept a mutable reference in their API.
         #[allow(clippy::unnecessary_mut_passed)]
         EventLoop {

and recreating the event-loop I get:

❯ RUST_BACKTRACE=1 RUST_LOG=debug cargo r --example emilk
warning: static `EVENT_LOOP_CREATED` is never used
   --> src/event_loop.rs:114:16
    |
114 |         static EVENT_LOOP_CREATED: OnceCell<()> = OnceCell::new();
    |                ^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(dead_code)]` on by default

warning: `winit` (lib) generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/examples/emilk`
Creating window "First Window"
TRACE [winit::platform_impl::platform::window] Triggered `WinitWindow::new`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `frameDidChange:`
TRACE [winit::platform_impl::platform::view] Completed `frameDidChange:`
TRACE [winit::platform_impl::platform::view] Triggered `viewDidMoveToWindow`
TRACE [winit::platform_impl::platform::view] Completed `viewDidMoveToWindow`
TRACE [winit::platform_impl::platform::window] Locked shared state in `WinitWindow::new`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `WinitWindow::new`
TRACE [winit::platform_impl::platform::window] Locked shared state in `set_fullscreen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `set_fullscreen`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::view] Triggered `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Completed `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Triggered `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Completed `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `WinitWindow::new`
TRACE [winit::platform_impl::platform::view] Triggered `drawRect:`
rendering
TRACE [winit::platform_impl::platform::view] Completed `drawRect:`
TRACE [winit::platform_impl::platform::app_delegate] Triggered `applicationDidFinishLaunching:`
TRACE [winit::platform_impl::platform::app_state] Activating visible window
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::app_delegate] Completed `applicationDidFinishLaunching:`
rendering
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowDidBecomeKey:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowDidBecomeKey:`
TRACE [winit::platform_impl::platform::view] Triggered `resetCursorRects`
TRACE [winit::platform_impl::platform::view] Completed `resetCursorRects`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowDidChangeOcclusionState:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowDidChangeOcclusionState:`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowDidChangeScreen:`
TRACE [winit::platform_impl::platform::window] Locked shared state in `window_did_change_screen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `window_did_change_screen`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowDidChangeScreen:`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowShouldClose:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowShouldClose:`
WindowEvent::CloseRequested
TRACE [winit::platform_impl::platform::window] Locked shared state in `fullscreen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `fullscreen`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowWillClose:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowWillClose:`
Event::LoopDestroyed.
-----------------
Creating window "Second Window"
TRACE [winit::platform_impl::platform::window] Triggered `WinitWindow::new`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Completed `validAttributesForMarkedText`
TRACE [winit::platform_impl::platform::view] Triggered `frameDidChange:`
TRACE [winit::platform_impl::platform::view] Completed `frameDidChange:`
TRACE [winit::platform_impl::platform::view] Triggered `viewDidMoveToWindow`
TRACE [winit::platform_impl::platform::view] Completed `viewDidMoveToWindow`
TRACE [winit::platform_impl::platform::window] Locked shared state in `WinitWindow::new`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `WinitWindow::new`
TRACE [winit::platform_impl::platform::window] Locked shared state in `set_fullscreen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `set_fullscreen`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeMainWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowDidBecomeKey:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowDidBecomeKey:`
TRACE [winit::platform_impl::platform::view] Triggered `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Completed `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Triggered `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::view] Completed `acceptsFirstResponder`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Triggered `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `canBecomeKeyWindow`
TRACE [winit::platform_impl::platform::window] Completed `WinitWindow::new`
thread 'main' panicked at 'The panic info must exist here. This failure indicates a developer error.', src/platform_impl/macos/app_state.rs:374:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
   2: core::panicking::panic_display
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:135:5
   3: core::panicking::panic_str
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:119:5
   4: core::option::expect_failed
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/option.rs:1879:5
   5: core::option::Option<T>::expect
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/option.rs:741:21
   6: winit::platform_impl::platform::app_state::AppState::cleared
             at ./src/platform_impl/macos/app_state.rs:372:26
   7: winit::platform_impl::platform::observer::control_flow_end_handler::{{closure}}
             at ./src/platform_impl/macos/observer.rs:79:21
   8: winit::platform_impl::platform::observer::control_flow_handler::{{closure}}
             at ./src/platform_impl/macos/observer.rs:41:9
   9: std::panicking::try::do_call
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:483:40
  10: ___rust_try
  11: std::panicking::try
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:447:19
  12: std::panic::catch_unwind
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panic.rs:137:14
  13: winit::platform_impl::platform::event_loop::stop_app_on_panic
             at ./src/platform_impl/macos/event_loop.rs:245:11
  14: winit::platform_impl::platform::observer::control_flow_handler
             at ./src/platform_impl/macos/observer.rs:39:5
  15: winit::platform_impl::platform::observer::control_flow_end_handler
             at ./src/platform_impl/macos/observer.rs:74:9
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <() as objc2::message::MessageArguments>::__invoke
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/mod.rs:390:26
  27: objc2::message::platform::send_unverified::{{closure}}
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/apple/mod.rs:36:33
  28: objc2::message::conditional_try
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/mod.rs:30:5
  29: objc2::message::platform::send_unverified
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/apple/mod.rs:36:14
  30: objc2::message::MessageReceiver::send_message
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/mod.rs:195:46
  31: winit::platform_impl::platform::appkit::application::NSApplication::run
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/macros/__rewrite_self_arg.rs:42:21
  32: winit::platform_impl::platform::event_loop::EventLoop<T>::run_return::{{closure}}
             at ./src/platform_impl/macos/event_loop.rs:220:22
  33: objc2::rc::autorelease::autoreleasepool
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/rc/autorelease.rs:313:5
  34: winit::platform_impl::platform::event_loop::EventLoop<T>::run_return
             at ./src/platform_impl/macos/event_loop.rs:211:25
  35: <winit::event_loop::EventLoop<T> as winit::platform::run_return::EventLoopExtRunReturn>::run_return
             at ./src/platform/run_return.rs:51:9
  36: emilk::main::show_window
             at ./examples/emilk.rs:23:9
  37: emilk::main
             at ./examples/emilk.rs:71:5
  38: core::ops::function::FnOnce::call_once
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:507:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/platform_impl/macos/event_loop.rs:253:55
stack backtrace:
   0: rust_begin_unwind
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
   2: core::panicking::panic
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:111:5
   3: core::option::Option<T>::unwrap
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/option.rs:778:21
   4: winit::platform_impl::platform::event_loop::stop_app_on_panic
             at ./src/platform_impl/macos/event_loop.rs:253:34
   5: winit::platform_impl::platform::observer::control_flow_handler
             at ./src/platform_impl/macos/observer.rs:39:5
   6: winit::platform_impl::platform::observer::control_flow_end_handler
             at ./src/platform_impl/macos/observer.rs:74:9
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <() as objc2::message::MessageArguments>::__invoke
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/mod.rs:390:26
  18: objc2::message::platform::send_unverified::{{closure}}
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/apple/mod.rs:36:33
  19: objc2::message::conditional_try
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/mod.rs:30:5
  20: objc2::message::platform::send_unverified
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/apple/mod.rs:36:14
  21: objc2::message::MessageReceiver::send_message
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/message/mod.rs:195:46
  22: winit::platform_impl::platform::appkit::application::NSApplication::run
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/macros/__rewrite_self_arg.rs:42:21
  23: winit::platform_impl::platform::event_loop::EventLoop<T>::run_return::{{closure}}
             at ./src/platform_impl/macos/event_loop.rs:220:22
  24: objc2::rc::autorelease::autoreleasepool
             at /Users/emilk/.cargo/registry/src/github.com-1ecc6299db9ec823/objc2-0.3.0-beta.3/src/rc/autorelease.rs:313:5
  25: winit::platform_impl::platform::event_loop::EventLoop<T>::run_return
             at ./src/platform_impl/macos/event_loop.rs:211:25
  26: <winit::event_loop::EventLoop<T> as winit::platform::run_return::EventLoopExtRunReturn>::run_return
             at ./src/platform/run_return.rs:51:9
  27: emilk::main::show_window
             at ./examples/emilk.rs:23:9
  28: emilk::main
             at ./examples/emilk.rs:71:5
  29: core::ops::function::FnOnce::call_once
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:507:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
TRACE [winit::platform_impl::platform::window] Locked shared state in `fullscreen`
TRACE [winit::platform_impl::platform::window] Unlocked shared state in `fullscreen`
TRACE [winit::platform_impl::platform::window_delegate] Triggered `windowWillClose:`
TRACE [winit::platform_impl::platform::window_delegate] Completed `windowWillClose:`

@rib
Copy link
Contributor

rib commented Mar 11, 2023

Just a stab in the dark atm but looking at the macos backend it has a double buffered control flow status (i.e the wait or exit status) for the event loop. (

control_flow: Mutex<ControlFlow>,
)

I suspicious atm about how that's being updated and read.

Setting the status to exit is what will cause the loop to exit after the first window is closed but then when re-running the loop it's notable that the status is only changed once the first event is read and dispatched.

As far as winit is concerned I think there's chance that the control flow status might be effectively read as "exit" when re-running the loop, before there is an opportunity to reset it.

Just a guess / hunch at the moment but I don't see anything that resets the control flow state in run_return. Initially it is simply Default initialized and stored in a global variable called HANDLER app_state.rs. I guess maybe run_return needs to make sure to reset this via some added AppState API

@rib
Copy link
Contributor

rib commented Mar 11, 2023

there are three callbacks for the second window though before it exits the loop so maybe that's a red herring.

rib added a commit to rib/winit that referenced this issue Apr 6, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we can stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431

TODO: Linux + MacOS support
rib added a commit to rib/winit that referenced this issue Apr 6, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we can stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431

TODO: Linux + MacOS support
rib added a commit to rib/winit that referenced this issue Apr 11, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

To help test the changes this adds:
  examples/window_ondemand
  examples/window_pump_events
  examples/window_pump_events_rfd

The last _rfd example, tests the interaction between the `rfd` crate and
using `pump_events` to embed Winit within an external event loop.

Additionally all examples have generally been updated so that `main()`
returns a `Result` from `run()`

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431
Fixes: rust-windowing#2752

TODO: Linux
TODO: split patch up
rib added a commit to rib/winit that referenced this issue Apr 11, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

To help test the changes this adds:
  examples/window_ondemand
  examples/window_pump_events
  examples/window_pump_events_rfd

The last _rfd example, tests the interaction between the `rfd` crate and
using `pump_events` to embed Winit within an external event loop.

Additionally all examples have generally been updated so that `main()`
returns a `Result` from `run()`

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431
Fixes: rust-windowing#2752

TODO: tidy up macos changes - probably lots of debug stuff left in atm
TODO: Linux
TODO: ask someone to test orbital changes, made blindly
TODO: split patch up
rib added a commit to rib/winit that referenced this issue Apr 12, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

To help test the changes this adds:
  examples/window_ondemand
  examples/window_pump_events
  examples/window_pump_events_rfd

The last _rfd example, tests the interaction between the `rfd` crate and
using `pump_events` to embed Winit within an external event loop.

Additionally all examples have generally been updated so that `main()`
returns a `Result` from `run()`

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431
Fixes: rust-windowing#2752

TODO: X11/Wayland backends
TODO: ask someone to test orbital changes, made blindly
TODO: split patch up

Second pass over the windows backend

I had totally underestimated what was involved in updating the windows
backend since I hadn't seen the special `wait_thread` that was also
dispatching messages and implementing control_flow timeouts via
MsgWaitForMultipleObjects, nor had I grokked all the special stuff being
done with `WM_PAINT` messages.

This "breaks" the MainEventsCleared -> RedrawRequested ->
RedrawEventsCleared ordering guarantees, similar to how this is anyway
inherently broken in the MacOS backend.

The switches to using SetTimer to handle control_flow Wait timeouts and
removes the need to use MsgWaitForMultipleObjects.

Overall this is a pretty nice simplification of several things

TODO: tidy up (lots of debug and misc changes + comments atm)

stash
rib added a commit to rib/winit that referenced this issue Apr 12, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

To help test the changes this adds:
  examples/window_ondemand
  examples/window_pump_events
  examples/window_pump_events_rfd

The last _rfd example, tests the interaction between the `rfd` crate and
using `pump_events` to embed Winit within an external event loop.

Additionally all examples have generally been updated so that `main()`
returns a `Result` from `run()`

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431
Fixes: rust-windowing#2752

TODO: X11/Wayland backends
TODO: ask someone to test orbital changes, made blindly
TODO: split patch up

Second pass over the windows backend

I had totally underestimated what was involved in updating the windows
backend since I hadn't seen the special `wait_thread` that was also
dispatching messages and implementing control_flow timeouts via
MsgWaitForMultipleObjects, nor had I grokked all the special stuff being
done with `WM_PAINT` messages.

This "breaks" the MainEventsCleared -> RedrawRequested ->
RedrawEventsCleared ordering guarantees, similar to how this is anyway
inherently broken in the MacOS backend.

The switches to using SetTimer to handle control_flow Wait timeouts and
removes the need to use MsgWaitForMultipleObjects.

Overall this is a pretty nice simplification of several things

TODO: tidy up (lots of debug and misc changes + comments atm)

stash
rib added a commit to rib/winit that referenced this issue Apr 12, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

To help test the changes this adds:
  examples/window_ondemand
  examples/window_pump_events
  examples/window_pump_events_rfd

The last _rfd example, tests the interaction between the `rfd` crate and
using `pump_events` to embed Winit within an external event loop.

Additionally all examples have generally been updated so that `main()`
returns a `Result` from `run()`

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431
Fixes: rust-windowing#2752

TODO: X11/Wayland backends
TODO: ask someone to test orbital changes, made blindly
TODO: split patch up

Second pass over the windows backend

I had totally underestimated what was involved in updating the windows
backend since I hadn't seen the special `wait_thread` that was also
dispatching messages and implementing control_flow timeouts via
MsgWaitForMultipleObjects, nor had I grokked all the special stuff being
done with `WM_PAINT` messages.

This "breaks" the MainEventsCleared -> RedrawRequested ->
RedrawEventsCleared ordering guarantees, similar to how this is anyway
inherently broken in the MacOS backend.

The switches to using SetTimer to handle control_flow Wait timeouts and
removes the need to use MsgWaitForMultipleObjects.

Overall this is a pretty nice simplification of several things

TODO: tidy up (lots of debug and misc changes + comments atm)

stash
rib added a commit to rib/winit that referenced this issue Apr 12, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

To help test the changes this adds:
  examples/window_ondemand
  examples/window_pump_events
  examples/window_pump_events_rfd

The last _rfd example, tests the interaction between the `rfd` crate and
using `pump_events` to embed Winit within an external event loop.

Additionally all examples have generally been updated so that `main()`
returns a `Result` from `run()`

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431
Fixes: rust-windowing#2752

TODO: X11/Wayland backends
TODO: ask someone to test orbital changes, made blindly
TODO: split patch up
rib added a commit to rib/winit that referenced this issue Apr 14, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

To help test the changes this adds:
  examples/window_ondemand
  examples/window_pump_events
  examples/window_pump_events_rfd

The last _rfd example, tests the interaction between the `rfd` crate and
using `pump_events` to embed Winit within an external event loop.

Additionally all examples have generally been updated so that `main()`
returns a `Result` from `run()`

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431
Fixes: rust-windowing#2752

TODO: X11/Wayland backends
TODO: ask someone to test orbital changes, made blindly
TODO: split patch up
rib added a commit to rib/winit that referenced this issue Apr 18, 2023
Overall this re-works the APIs for how an `EventLoop` is run to cover
these use-cases, with varying portability caveats:

1. A portable `run()` API that consumes the `EventLoop` and runs the
   loop on the calling thread until the app exits. This can be
   supported across _all_ platforms and compared to the previous
   `run() -> !` API is now able to return a `Result` status on all platforms
   except iOS and Web. Fixes: rust-windowing#2709
2. A less portable `run_ondmand()` API that covers the use case in rust-windowing#2431
   where applications need to be able to re-run a Winit application
   multiple times against a persistent `EventLoop`. This doesn't allow
   `Window` state to carry across separate runs of the loop, but does
   allow orthogonal re-instantiations of a gui application.

   Available On: Windows, Linux, MacOS
   Could be supported on Android if there's a use case
   Incompatible with iOS, Web
   Fixes: rust-windowing#2431
3. A less portable (and on MacOS, likely less-optimal) `pump_events()`
   API that covers the use case in rust-windowing#2706 and allows a Winit event loop to
   be embedded within an external `loop {}`. Applications call `pump_events()`
   once per iteration of their own external loop to dispatch all pending Winit
   events, without blocking the external loop.

   Available On: Windows, Linux, MacOS, Android
   Incompatible With: iOS, Web
   Fixes: rust-windowing#2706

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

In particular by moving away from `run() -> !` we stop calling
`std::process::exit()` internally as a means to kill the process without
returning which means it's possible to return an exit status and
applications can return from their `main()` function normally. This also
fixes Android support where an Activity runs in a thread but we can't
assume to have full ownership of the process (other services could be
running in separate threads).

`run_return` has been removed, and the overlapping use cases that
`run_return` previously partially aimed to support have been split
across `run_ondemand` and `pump_events`.

To help test the changes this adds:
  examples/window_ondemand
  examples/window_pump_events
  examples/window_pump_events_rfd

The last _rfd example, tests the interaction between the `rfd` crate and
using `pump_events` to embed Winit within an external event loop.

Additionally all examples have generally been updated so that `main()`
returns a `Result` from `run()`

Fixes: rust-windowing#2709
Fixes: rust-windowing#2706
Fixes: rust-windowing#2431
Fixes: rust-windowing#2752

TODO: X11/Wayland backends
TODO: ask someone to test orbital changes, made blindly
TODO: split patch up
rib added a commit to rib/winit that referenced this issue Jun 18, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicitly, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 18, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicitly, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 22, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicitly, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 22, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 22, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 22, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 25, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 25, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 25, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 26, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jun 26, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jul 4, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
@kchibisov kchibisov added this to the Version 0.29.0 milestone Jul 11, 2023
@parasyte parasyte mentioned this issue Jul 17, 2023
17 tasks
rib added a commit to rib/winit that referenced this issue Jul 24, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
rib added a commit to rib/winit that referenced this issue Jul 25, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
kchibisov pushed a commit that referenced this issue Jul 27, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing #2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing #2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
kchibisov pushed a commit to kchibisov/winit that referenced this issue Aug 14, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing rust-windowing#2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing rust-windowing#2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
kchibisov pushed a commit that referenced this issue Aug 15, 2023
This adds two new extensions for running a Winit event loop which will
replace `EventLoopExtRunReturn`

The `run_return` API is trying to solve multiple problems and address
multiple, unrelated, use cases but in doing so it is not succeeding
at addressing any of them fully.

The notable use cases we have are:
1. Applications want to be able to implement their own external
   event loop and call some Winit API to poll / pump events, once
   per iteration of their own loop, without blocking the outer,
   external loop. Addressing #2706
2. Applications want to be able to re-run separate instantiations
   of some Winit-based GUI and want to allow the event loop to exit with
   a status, and then later be able to run the loop again for a new
   instantiation of their GUI. Addressing #2431

It's very notable that these use cases can't be supported across
all platforms and so they are extensions, similar to
`EventLoopExtRunReturn`

The intention is to support these extensions on:
- Windows
- Linux (X11 + Wayland)
- macOS
- Android

These extensions aren't compatible with Web or iOS though.

Each method of running the loop will behave consistently in terms of how
`NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched
(so portable application code wouldn't necessarily need to have any awareness
of which method of running the loop was being used)

Once all backends have support for these extensions then we can
remove `EventLoopExtRunReturn`

For simplicity, the extensions are documented with the assumption that
the above platforms will be supported.

This patch makes no functional change, it only introduces these new
extensions so we can then handle adding platform-specific backends
in separate pull requests, so the work can be landed in stages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DS - macos H - help wanted Someone please save us
Development

Successfully merging a pull request may close this issue.

5 participants