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

How do I build a new window inside run_forever or poll_events? #413

Closed
wez opened this issue Mar 2, 2018 · 7 comments · Fixed by #913
Closed

How do I build a new window inside run_forever or poll_events? #413

wez opened this issue Mar 2, 2018 · 7 comments · Fixed by #913
Labels
C - waiting on author Waiting for a response or another PR D - hard Likely harder than most tasks here F - question There's no such thing as a stupid one P - normal Great to have S - api Design and usability
Milestone

Comments

@wez
Copy link

wez commented Mar 2, 2018

I'd like to be able to spawn a new window in response to user input.

Since the event loop is borrowed mutably by run_forever and poll_events, there doesn't appear to be a way to spawn new windows in response to input events.

This may be another facet of #231

@jwilm
Copy link
Contributor

jwilm commented Mar 2, 2018

One option is to simply break out of the event loop in that case:

loop {
    let mut flag = false;
    events.run_forever(|event| {
        match event {
            // Event you care about
            flag = true;
            return ControlFlow::Break;
        }
    });
    if flag {
        windows.push(Window::new(&events));
    }
}

@wez
Copy link
Author

wez commented Mar 2, 2018

Sure, but that's not inside the callback :-p
I'm using run_forever for maximum idle reasons, so if I have to break out of the loop its now on me to find a way to efficiently sleep without lagging on processing events per all of the discussion in #231.

@wez
Copy link
Author

wez commented Mar 2, 2018

oh, I misread your comment; I didn't really notice that you could call run forever again

@francesca64 francesca64 added F - question There's no such thing as a stupid one S - api Design and usability C - waiting on author Waiting for a response or another PR D - hard Likely harder than most tasks here P - normal Great to have labels May 6, 2018
@francesca64 francesca64 added this to the EventsLoop 2.0 milestone May 6, 2018
@marek-g
Copy link

marek-g commented Jul 21, 2018

I've encountered the same problem.

I think what could be easily done to solve the problem is to add &mut EventsLoop parameter to the callback:

events.run_forever_mut(|event, events| { .... /* you can now use "events" to create new window here */ }

I hope rust allows it :)

To have backward compatible API it could be a new method like run_forever_mut.

--

Or.. other idea.. is to use interior mutability for EventsLoop. In that case it would be easy to pass the reference to EventLoop anywhere.

@Osspial
Copy link
Contributor

Osspial commented Apr 24, 2019

This should be fixed by the EventLoop 2.0 API rework, when that gets merged.

tmfink pushed a commit to tmfink/winit that referenced this issue Jan 5, 2022
@MendyBerger
Copy link

Now you'd use the EventLoopWindowTarget that you get in the run method, right?

@daxpedda
Copy link
Member

Yes, new windows are created with Window::new() , which takes a EventLoopWindowTarget.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - waiting on author Waiting for a response or another PR D - hard Likely harder than most tasks here F - question There's no such thing as a stupid one P - normal Great to have S - api Design and usability
Development

Successfully merging a pull request may close this issue.

7 participants