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

Compose/dead keys break on MacOS in version 0.25 #2040

Open
xeniagda opened this issue Oct 26, 2021 · 3 comments
Open

Compose/dead keys break on MacOS in version 0.25 #2040

xeniagda opened this issue Oct 26, 2021 · 3 comments

Comments

@xeniagda
Copy link

Hello. When compiling a custom fork of alacritty, I tried upgrading winit to 0.25 from version 0.24. While everything seemed to have worked fine, an issue arose when I tried to use a dead key.

The behaviour in 0.25 seems to be that when the compose key is pressed, a ReceivedCharacter event is produced with the terminator char for the dead key, and when another character is pressed (which should normally be turned into the corresponding char from the dead key state), it does not trigger a ReceivedCharacter event. The correct behaviour would be to not produce a ReceivedCharacter event when the dead key is pressed, and produce a ReceivedCharacter event for the key pressed after the dead key is pressed, which is what version 0.24 does.

I will try to produce an explicit minimal reproducible example of the problem when I have time, but the instructions above should be enough to reproduce the behaviour in any application that responds to characters typed by the user.

@xeniagda
Copy link
Author

Doing a git bisect shows that pull request #1979 (comment) is the offending pull request, and that commit 077d264 in the fork (the last commit) is the exact point behaviour is introduced.

@xeniagda
Copy link
Author

Hmm, after reading the thread, it seems like the indented behaviour is:

  1. When the user types a dead key, send the dead key character as a ReceivedChar
  2. When the user types the next key, send as many DELETEs as the dead key character is long
  3. Send the actual character the user wanted.

However, what seems to happen is:

  1. When the user types a dead key, send the dead key character as a ReceivedChar
  2. The user presses the next key. No ReceivedChar-event is produced.

@xeniagda
Copy link
Author

Also, I guess I should give some more exact instructions to reproduce:

use winit::{
    event::{Event, WindowEvent},
    event_loop::{ControlFlow, EventLoop},
    window::WindowBuilder,
};

fn main() {
    let event_loop = EventLoop::new();

    let window = WindowBuilder::new()
        .with_inner_size(winit::dpi::LogicalSize::new(128.0, 128.0))
        .build(&event_loop)
        .unwrap();

    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;
        match event {
            Event::WindowEvent {
                event: WindowEvent::CloseRequested,
                window_id,
            } if window_id == window.id() => *control_flow = ControlFlow::Exit,
            Event::WindowEvent {
                event: WindowEvent::ReceivedCharacter(c),
                ..
            } => {
                println!("Pressed {:?}", c);
            }
            Event::WindowEvent {
                event: e@WindowEvent::KeyboardInput { .. },
                ..
            } => {
                // println!("KeyboardInputted {:?}", e);
            }
            _ => (),
        }
    });
}

is a simple program that simply println!s all ReceivedChar events it receives.

Using the Swedish Pro layout (or any other layout with a dead key), press the ´-key (top right key, to the left of backspace), then press a. In versions v0.24 and prior, this produces an output of Pressed 'á' as the a-key is pressed. In versions 0.25 and after, this gives the output Pressed '´' when the dead key is pressed, and no output when the a-key is pressed.

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

No branches or pull requests

2 participants