Feature: Extend EguiEvent::Key of it's text representation

[obsoleszenz]

This pr adds the text representation of the key to the EguiEvent::Key struct. This way we get the character that the keyboard layout actually represents and not only the key combination. For example on EurKey layout, if i press AltRight+A, it's mapped to "ä". Key { key: A, physical_key: Some(A), pressed: false, repeat: false, modifiers: Modifiers::NONE, text: Some("ä") }

• Addresses https://github.com/emilk/egui/discussions/1590
• [x] I have followed the instructions in the PR template

[obsoleszenz]

@emilk If you understand this better and approve it to be the way to go i will write a docstring and add the lost comment back :)

[emilk]

I think this makes sense, but I still haven't understood a concrete use case for this. If you use KeyEvent::text and ignore Event::Text, then you miss some events (e.g. IME text, clipboard paste text, etc). If you use both, then you get duplicated text.

What is the concrete problem you are trying to solve?

[obsoleszenz]

I think this makes sense, but I still haven't understood a concrete use case for this. If you use KeyEvent::text and ignore Event::Text, then you miss some events (e.g. IME text, clipboard paste text, etc). If you use both, then you get duplicated text.

What is the concrete problem you are trying to solve?

I give you an example of what i currently do: I'm using egui mainly for painting, not using the input widgets. But i have my own implementations of it, as i focus on having the whole app controllable with the keyboard (think game). So for example i have a popup which allows editing some text, one can open it by pressing Esc, followed by e. If the user now presses any keys it will edit/insert the text, escape closes the popup, enter saves. But I want to support ä/ü... which is mapped on my keyboard to Alt+a & Alt+u.

I get following events:

• Egui::Event::Key { ... Escape } => Open main menu popup
• Egui::Event::Key { ... 'e' } => switch to edit text popup
• Egui::Event::Text("e") => We now insert text "e" and there's no way to know that we processed this event as Event::Key already
• Egui::Event::Key(Alt(a)) => We don't know that this represents "ä", so we ignore
• Egui::Event::Text("ä") => Insert "ä"

[emilk]

Thanks for explaining this in more detail! It seems the core need is to be able to match a specific Key event to a specific Text event, and the other way around. The proposed solution is one way of doing so, but I'm not sure it's the best way.

Or rather, maybe it doesn't go far enough 🤔 If we add Option<String> to Event::Key, we should also remove Event::Text. I earlier misremembered and thought we used Event::Text for non-key events too, like paste and IME, but those have their own events. So I think Event::Text is safe to be removed (or rather moved into Event::Key).

[obsoleszenz]

Thanks for explaining this in more detail! It seems the core need is to be able to match a specific Key event to a specific Text event, and the other way around. The proposed solution is one way of doing so, but I'm not sure it's the best way.

Or rather, maybe it doesn't go far enough 🤔 If we add Option<String> to Event::Key, we should also remove Event::Text. I earlier misremembered and thought we used Event::Text for non-key events too, like paste and IME, but those have their own events. So I think Event::Text is safe to be removed (or rather moved into Event::Key).

Happy that I could clarify :) Yes I think removing Event::Text is the way to go. I think we can introduce text: Option<String> and mark Event::Text as deprecated with a note to use Event::Key.text instead.

If we agree on this i can update this PR to do that.

[emilk]

go for it!

[obsoleszenz]

@emilk added docstring, deprecated Event::Text and changed all usages in the codebase to Event::Key.

[obsoleszenz]

@emilk hey hey this pr should be ready. Maybe you find some time to check/merge?