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

Exposing the existing AndroidApp in the public API #3818

Closed
mwcampbell opened this issue Jul 24, 2024 · 0 comments · Fixed by #3828
Closed

Exposing the existing AndroidApp in the public API #3818

mwcampbell opened this issue Jul 24, 2024 · 0 comments · Fixed by #3828

Comments

@mwcampbell
Copy link

For my work on accesskit_winit, it would be helpful if winit exposed the existing AndroidApp instance in the public API, e.g. through an android_app method on ActiveEventLoopExtAndroid.

It's true that the top-level application already has the AndroidApp instance, since it has to pass that to winit in the first place. But that's not enough for accesskit_winit, for two reasons:

  1. Directly passing the AndroidApp instance from the application to accesskit_winit would require accesskit_winit to have a platform-specific adapter constructor for Android, and I'm trying to avoid platform-specific things in the accesskit_winit API, since the point of winit is to be cross-platform.
  2. Having the application directly pass the AndroidApp instance to accesskit_winit would also break the layering that tends to happen in non-trivial applications. Consider that accesskit_winit::Adapter is typically instantiated by a cross-platform framework like eframe or masonry.
@kchibisov kchibisov added this to the Version 0.30.5 milestone Jul 26, 2024
kchibisov added a commit that referenced this issue Jul 26, 2024
This type comes from the user and stored for the entire lifetime, so
no need to hide it from them after they've passed it to winit.

Fixes #3818.
kchibisov added a commit that referenced this issue Jul 26, 2024
This type comes from the user and stored for the entire lifetime, so
no need to hide it from them after they've passed it to winit.

Fixes #3818.
kchibisov added a commit that referenced this issue Jul 26, 2024
This type comes from the user and stored for the entire lifetime, so
no need to hide it from them after they've passed it to winit.

Fixes #3818.
kchibisov added a commit that referenced this issue Jul 26, 2024
This type comes from the user and stored for the entire lifetime, so
no need to hide it from them after they've passed it to winit.

Fixes #3818.
kchibisov added a commit that referenced this issue Aug 7, 2024
This type comes from the user and stored for the entire lifetime, so
no need to hide it from them after they've passed it to winit.

Fixes #3818.
kchibisov added a commit that referenced this issue Aug 7, 2024
This type comes from the user and stored for the entire lifetime, so
no need to hide it from them after they've passed it to winit.

Fixes #3818.
kchibisov added a commit that referenced this issue Aug 8, 2024
This type comes from the user and stored for the entire lifetime, so
no need to hide it from them after they've passed it to winit.

Fixes #3818.
rib pushed a commit to EmbarkStudios/winit that referenced this issue Aug 12, 2024
This type comes from the user and stored for the entire lifetime, so
no need to hide it from them after they've passed it to winit.

Fixes rust-windowing#3818.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants