rust-windowing
Support handling any event on macOS
Implements #2120 for macOS
- [ ] Tested on all platforms changed
- [ ] Added an entry to
CHANGELOG.mdif knowledge of this change could be valuable to users - [ ] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
- [ ] Created or updated an example program if it would help users understand this functionality
- [ ] Updated feature matrix, if new features were added or implemented
@madsmtm I think I'm making good progress with this but I hit an issue that I don't understand.
The idea is that I always declare a new delegate class when a new callback is added. The new delegate subclasses the previous one to allow having mutliple callbacks on one method. This also means that the delegate handler must call the superclass' method. But when I do this, it recurses infinitely and I get a sweet stack overflow.
If you execute the "native_events" example it hits an infinite recursion. But as far as I understand, it shouldn't.
Here's where the recurson happens, but I don't get why https://github.com/rust-windowing/winit/pull/2141/files#diff-e84f3d0ef4443d7dac0b6443d49905fc86537ac06a4b3e1cbf5a79988962f223R217-R231
The idea is that I always declare a new delegate class when a new callback is added.
Can you base this off of the EventLoopBuilder added in #2137 instead, and then create a single delegate class for downstream callbacks?
The idea is that I always declare a new delegate class when a new callback is added.
Can you base this off of the
EventLoopBuilderadded in #2137 instead, and then create a single delegate class for downstream callbacks?
Technically yes, but that would make a very unpractical API for users. See: https://github.com/rust-windowing/winit/issues/2120#issuecomment-1005529724
But anyways, I think I managed to resolve (ie work around) the issue.
@maroider Had an idea for how we could change things so that all of us can be happy. I won't go into the details but the fundamental idea is that there is a user-defined State object that the event loop owns and passes to each user callback as a parameter, so that things created after the event loop, can still be provided to custom event closures. But I think we gonna have to wait for @maroider to make the proposal officially to discuss it.