Unfortunately no, this doesn't solve the issue for some reason. Here is the trace when I hit:

• shift-1
• cmd-shit-1

[2024-01-05T07:58:06Z TRACE egui_winit] Unknown key: Shift
[2024-01-05T07:58:06Z TRACE egui_winit] logical Named(Shift) -> None,  physical Code(ShiftLeft) -> None
[2024-01-05T07:58:07Z TRACE egui_winit] logical Character("+") -> Some(Plus),  physical Code(Digit1) -> Some(Num1)
[2024-01-05T07:58:07Z TRACE egui_winit] logical Character("+") -> Some(Plus),  physical Code(Digit1) -> Some(Num1)
[2024-01-05T07:58:08Z TRACE egui_winit] Unknown key: Shift
[2024-01-05T07:58:08Z TRACE egui_winit] logical Named(Shift) -> None,  physical Code(ShiftLeft) -> None
[2024-01-05T07:58:09Z TRACE egui_winit] Unknown key: Shift
[2024-01-05T07:58:09Z TRACE egui_winit] logical Named(Shift) -> None,  physical Code(ShiftLeft) -> None
[2024-01-05T07:58:09Z TRACE egui_winit] Unknown key: Super
[2024-01-05T07:58:09Z TRACE egui_winit] logical Named(Super) -> None,  physical Code(SuperLeft) -> None
[2024-01-05T07:58:09Z TRACE egui_winit] logical Character("1") -> Some(Num1),  physical Code(Digit1) -> Some(Num1)
[2024-01-05T07:58:09Z TRACE egui_winit] logical Character("1") -> Some(Num1),  physical Code(Digit1) -> Some(Num1)
[2024-01-05T07:58:09Z TRACE egui_winit] Unknown key: Super
[2024-01-05T07:58:09Z TRACE egui_winit] logical Named(Super) -> None,  physical Code(SuperLeft) -> None
[2024-01-05T07:58:09Z TRACE egui_winit] Unknown key: Shift
[2024-01-05T07:58:09Z TRACE egui_winit] logical Named(Shift) -> None,  physical Code(ShiftLeft) -> None

Running on macOS Sonoma 14.1.1

shift-1 is where the + is in the ch-fr keyboard:

(Bonus keyboard layout trivia: the weird glyph layout in the "é/ö" keys and neighbours is due to the fact that there are two sub-layouts: swiss-french and swiss-german. The only difference between the two is "éèà" by default / "öäü" with shift for the swiss-french, and the opposite for the swiss-gemeran.)

Seems like we are hitting this winit bug: rust-windowing/winit#3078

Fix for winit in rust-windowing/winit#3361

This should do the right think on Windows and Linux (I hope), but for macOS we have to wait for rust-windowing/winit#3361

My application was distinguishing between shortcuts with and without Shift, which this breaks. It also causes surprising behavior:

let change = if i.consume_key(Modifiers::COMMAND | Modifiers::SHIFT, Key::Plus) {
    // correctly captures Command-Shift-Plus, even though it shouldn't anymore?
    10
} else if i.consume_key(Modifiers::COMMAND, Key::Plus) {
    // never triggers
    1
} else if i.consume_key(Modifiers::COMMAND | Modifiers::SHIFT, Key::Minus) {
    // never triggers
    -10
} else if i.consume_key(Modifiers::COMMAND, Key::Minus) {
    // correctly captures Command-Minus
    -1
} else {
    return;
};

If not for consume_key(Modifiers::COMMAND, Key::Plus) no longer working I would be able to replicate the previous behavior by also checking i.modifiers.shift

Possibly related: when upgrading from 0.23.0 to 0.27.1 I had to set zoom_with_keyboard = false to avoid Command-Plus from being turned into a zoom event, despite the consume_key call.

This almost replicates the previous behavior, except that Command-Shift-Minus doesn't seem to create a InputState event anymore.

let mut change = None;
i.events.retain(|event| {
    match event {
        Event::Key { physical_key: Some(Key::Equals), modifiers, pressed: true, .. } => {
            change = Some(if modifiers.shift { 10 } else { 1 });
            false
        }
        Event::Key { physical_key: Some(Key::Minus), modifiers, pressed: true, .. } => {
            change = Some(if modifiers.shift { -10 } else { -1 });
            false
        }
        _ => true,
    }
});

Pressing shift and minus at the same time will on my keyboard produce the underscore character: _, i.e not a Key::Minus.

You are trying to check for a physical key, when egui uses logical keys.

See https://docs.rs/egui/latest/egui/enum.Event.html#variant.Key and #3653 for more