libsdl-org
SDL stops sending key events if key compositions/ime ui related actions are being processed
I recently updated to the latest commit, and I noticed if I use
SDL_StartTextInput(), SDL stops sending key events if key compositions/ime ui related actions are being processed. It's usually the desired behavior, but for compositions like option + n, that triggers ˜ composition for english keyboard, there's no way to get the normal key events which I need if option key is interpreted as meta. Could it be possible to add such option (for example, disable left/right option and other modifiers for TextInput), or send the keyboard events anyways and add a flag to indicate it shouldn't be processed?
Originally posted by @williamhCode in https://github.com/libsdl-org/SDL/issues/3559#issuecomment-2262317150
@williamhCode, is this still true in the latest SDL main code? If so, what platform are you seeing this happen?
I looked into this, and this is consistent with behavior on other platforms, and on some platforms the keys are entirely hidden from the application.
I'm going to leave this open for discussion, but I'm going to bump it out of the shipping milestone while we figure out what we want here.
After some more investigation, we're going to see if we can make all platforms work the way you're looking for here.
It turns out we can't. I'll probably gate the behavior in #11842 behind a hint and default it off, for consistency across platforms.
I see, so there's no guarantee that the keys will pass through for every platform, but the hint will enable it for platforms that do support it.
How critical is this to you? This opens up a footgun for people who get keystrokes that are used for navigating IME UI, for example Japanese candidates or selecting Chinese phrases.
I don't think that is a concern. Users can expect that their keys will be eaten when navigating the IME UI for languages like Japanese and Chinese.
As long as the keys can pass through on macOS, it should be good, because it's the only platform with an option key which isn't directly interpreted as alt/meta.
On other platforms keys like alt-n, i, or e wouldn't trigger an ime sequence, but on macOS the corresponding keys pressed with option does, and which is why it's more important that I can get the pass through keys on macOS.
If option+n triggers a ~ composition sequence then shouldn't you respect that and ignore the option in that case?
Note that all of this is only relevant in text input mode in which case you should largely be ignoring key events anyway and just interpret TEXTINPUT events. Is there a use case I'm missing here?
For macOS terminals there's usually an option to treat the option key at meta/alt. Since option + letters triggers special characters like å and combination like ã, most of the time users in a terminal/text editor would want to ignore that and send meta + letter instead which is useful for key mappings. Basically it's treating the option key and meta key as two separate keys. Users should be able to change either the left, right or both option keys to meta.
So even while in text input mode, I need the users to be able to send meta + letter instead of option + letter.
But to even if the events are passed through and I do treat option as meta, I'll have to disable and enable text event if I detect meta to clear the composition, which is very hacky.
After a bit more research...
I was looking at how Neovide (neovim gui written in rust) handled this specific case, and winit has a macos specific function called set_option_as_alt. Winit directly modifies the event NSEvent received to do this here
Perhaps this should be a separate issue, specifically to treat option as alt/meta key on macOS. It makes more sense to implement this specific case rather than passing the key events through since it boils down to this one case.
After a bit more research...
I was looking at how Neovide (neovim gui written in rust) handled this specific case, and winit has a macos specific function called set_option_as_alt. Winit directly modifies the event NSEvent received to do this here
Perhaps this should be a separate issue, specifically to treat option as alt/meta key on macOS. It makes more sense to implement this specific case rather than passing the key events through since it boils down to this one case.
That makes way more sense to me. Thanks for doing the legwork to find a better solution!
If I remember right, users can also do this in the system keyboard settings as well.
That makes way more sense to me. Thanks for doing the legwork to find a better solution!
No problem!
If I remember right, users can also do this in the system keyboard settings as well.
I don't think users can do this without using external apps. You can map option to no action, but that disables the option key completely.
But in any case, I would like to have this functionality in my gui and I'm willing to contribute.
But in any case, I would like to have this functionality in my gui and I'm willing to contribute.
Okay, feel free to create a PR with a hint to remap the Option key. You can look at SDL_HINT_QUIT_ON_LAST_WINDOW_CLOSE for a simple example.