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

Clarification on dead keys #343

Closed
k0nserv opened this issue Nov 5, 2017 · 3 comments
Closed

Clarification on dead keys #343

k0nserv opened this issue Nov 5, 2017 · 3 comments
Labels
DS - macos S - api Design and usability S - platform parity Unintended platform differences

Comments

@k0nserv
Copy link

k0nserv commented Nov 5, 2017

I did some reasearch based on #263 using a simple macOS app that just logs keyDown events. With my layout(based on Swedish Pro) ^, ¨, ~ don't work correctly since they are dead keys. Handling dead keys involves quite a bit more work that needs to be done in winit. I'm curious if handling dead keys is considered in scope for winit or if that's something that you expect applications themselves to deal with.

Also see alacritty/alacritty#682

@tomaka tomaka added the S - api Design and usability label Nov 6, 2017
@elinorbgr
Copy link
Contributor

elinorbgr commented Nov 6, 2017

For comparison, the wayland platforms automatically handles dead keys. By that I mean that for example:

  • User presses ^ key (which is a dead key on my azerty keyboard)
  • winit generates a KeyPressed event for key ^ but no ReceivedCharacter event
  • User then presses e key
  • winit generates a KeyPressed event for key e, then a ReceivedCharacted('ê')

So we have a discrepancy between backends, time to decide what to converge to.

@tomaka
Copy link
Contributor

tomaka commented Nov 6, 2017

What @vberger described is what should happen IMO. That's also currently the behaviour on Windows.

@ghost
Copy link

ghost commented Apr 10, 2018

@francesca64 francesca64 added the S - platform parity Unintended platform differences label May 6, 2018
@Osspial Osspial added this to the Keyboard Events Overhaul milestone Apr 24, 2019
tmfink pushed a commit to tmfink/winit that referenced this issue Jan 5, 2022
tmfink pushed a commit to tmfink/winit that referenced this issue Jan 5, 2022
kchibisov added a commit that referenced this issue May 28, 2023
Overhaul the keyboard API in winit to mimic the W3C specification
to achieve better crossplatform parity. The `KeyboardInput` event
is now uses `KeyEvent` which consists of:

  - `physical_key` - a cross platform way to refer to scancodes;
  - `logical_key`  - keysym value, which shows your key respecting the
                     layout;
  - `text`         - the text produced by this keypress;
  - `location`     - the location of the key on the keyboard;
  - `repeat`       - whether the key was produced by the repeat.

And also a `platform_specific` field which encapsulates extra
information on desktop platforms, like key without modifiers
and text with all modifiers.

The `Modifiers` were also slightly reworked as in, the information
whether the left or right modifier is pressed is now also exposed
on platforms where it could be queried reliably. The support was
also added for the web and orbital platforms finishing the API
change.

This change made the `OptionAsAlt` API on macOS redundant thus it
was removed all together.

Co-Authored-By: Artúr Kovács <kovacs.artur.barnabas@gmail.com>
Co-Authored-By: Kirill Chibisov <contact@kchibisov.com>
Co-Authored-By: daxpedda <daxpedda@gmail.com>
Fixes: #2631.
Fixes: #2055.
Fixes: #2032.
Fixes: #1904.
Fixes: #1810.
Fixes: #1700.
Fixes: #1443.
Fixes: #1343.
Fixes: #1208.
Fixes: #1151.
Fixes: #812.
Fixes: #600.
Fixes: #361.
Fixes: #343.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DS - macos S - api Design and usability S - platform parity Unintended platform differences
Development

No branches or pull requests

5 participants