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

android: ignore volume keys #1919

Closed
wants to merge 2 commits into from
Closed

Conversation

alula
Copy link
Contributor

@alula alula commented Apr 28, 2021

  • Tested on all platforms changed
  • Compilation warnings were addressed
  • cargo fmt has been run on this branch
  • cargo doc builds successfully
  • Added an entry to CHANGELOG.md if 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

@msiglreith msiglreith added DS - android C - waiting on maintainer A maintainer must review this code labels May 2, 2021
@msiglreith msiglreith self-requested a review May 2, 2021 20:50
Copy link
Member

@msiglreith msiglreith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, fine for me

cc @MarijnS95 to check that you don't require it by chance

@MarijnS95
Copy link
Member

I miss proper justification why this is disabled. The main problem appears to be that winit marks every key as "handled" regardless of what the application does with it.

What if someone built an audio application with Winit and listens for volume keys for some reason or another, and suddenly doesn't receive them anymore?

Besides, we're at 65 characters of indentation now, this is getting beyond maintainable.

@maroider
Copy link
Member

maroider commented May 6, 2021

The main problem appears to be that winit marks every key as "handled" regardless of what the application does with it.

It seems like there's a need to expose the ability to set the "handled" state of certain events, and not just on Android (see #1768).

@torokati44
Copy link
Contributor

It seems like there's a need to expose the ability to set the "handled" state of certain events, and not just on Android

I definitely agree, but until that, as a stopgap, I'd love to see this merged!

@msiglreith
Copy link
Member

Fixed by #2748

@msiglreith msiglreith closed this Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - waiting on maintainer A maintainer must review this code DS - android
Development

Successfully merging this pull request may close these issues.

None yet

5 participants