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

window resize callback should accept closures #859

Closed
swiftcoder opened this issue Feb 18, 2017 · 4 comments
Closed

window resize callback should accept closures #859

swiftcoder opened this issue Feb 18, 2017 · 4 comments

Comments

@swiftcoder
Copy link

Currently, the window resize callback is a plain function pointer, which precludes the use of closures or instance methods.

This pretty much requires the use of static data to allow whatever callback you define to access instance data, which makes the library rather an unergonomic application of Rust.

Accepting closures would allow us to capture self and hence bind instance methods to the callback slot.

@tomaka
Copy link
Contributor

tomaka commented Feb 18, 2017

That would be unsound unfortunately, because of leak safety (search for "thread scoped rust leakpocalypse" if you want to know more, it's a tought problem).

The resize callback is going to go away at some point: rust-windowing/winit#20

@swiftcoder
Copy link
Author

Fair. Event loops are likely the better way to solve this.

Is there any recommended workaround in the meantime?

@mitchmindtree
Copy link
Contributor

@swiftcoder not other than using some sort of static data like you mention unfortunately. On the bright side, the issue that tomaka linked to has mostly been implemented upstream in rust-windowing/winit#126 and rust-windowing/winit#132, so it's mostly just a matter of waiting for the dust to settle so that winit can publish a new version, and then updating glutin to match the new winit API.

@francesca64
Copy link
Member

Since resize callbacks no longer exist, this can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants