I’m writing an IDE/text editor (depends how popular it becomes)
What would be the most ‘correct’ way of handling input? I haven’t used a non us keyboard and I have no idea how people type non-ascii letters. I imagine OSes understand which keycode map to what characters? and a user may have a shortcut to switch between layouts? (ascii for code ↔ a keyboard for their native language?)
I see SDL_Keycode is 32bits, I already look at keydown to handle in editor keyboard shortcuts, do I use key (which is type SDL_Keycode) for the unicode value? I don’t need to mix it with previous or next keys? I don’t use SDL_StartTextInput which sounds like it starts up an on screen keyboard for mobile devices? BTW at the moment I only plan to support linux, mac and likely windows
I read BestKeyboardPractices and under text editor it says “you would need to handle both key events and input events as above” but I’m not 100% why looking at key.key as described above isn’t enough?
I noticed there’s a SDL_GetKeyboards function. Maybe I can do something special when there’s no keyboard attached but I have no idea how I’d get that to work well and it’s not my target set of platforms so I shouldn’t spend too much time on that
Honestly, your life is going to be a lot easier if you use an actual GUI library. wxWidgets is good, cross-platform, and uses the native OS GUI stuff under the hood, so your app will look and feel like a native app. The input handling, including text entry, would be handled by the OS and the library, and your app would get the result.
If you just have to use SDL to make a text editor and build everything yourself from scratch, use SDL_Start/StopTextInput() and then handle the SDL_EVENT_TEXT_INPUT events. If necessary, SDL will bring up the system IME interface for certain languages (which may not map directly to single keys on the keyboard). The SDL_EVENT_TEXT_INPUT event will give you the UTF-8 for the input the user gave. You will still have to handle backspace, modifiers, arrow keys, etc., yourself.
edit: if you absolutely need to use SDL, consider using something like Dear ImGui, which has text input areas that handle text input for you, and you just ask it for the text when you need it.
Too late, that ship has sailed. I have LSPs DAPs and more implemented. There’s pics on the website if you want to see how it looks before the rewrite.
SDL will bring up the system IME interface
That’s the part I’m having a hard time imagining. I seen people on this forum “code on mobile” which sounds like a terrible time, I have no idea how to make it reasonable. Specifically when to close the IME keyboard (any tap outside of it?) and how to decide if a tap is to set the cursor, to open the IME, an accidental touch, or the first of two taps to highlight a word. I guess waiting 500ms would solve the last case.
You will still have to handle backspace, modifiers, arrow keys, etc., yourself.
That’s fine, but I’m not sure if for my usecase it’d be easier to use sdl keydown event and look at the key? My opening post ask if I’ll need to look at the previous keypress for unicode input. I look at every keypress for one reason or another (keyboard shortcuts)
I just noticed that SDL_Keycode could be confused with SDL_Scancode in discussion
ask it for the text when you need it.
That’s the thing, it’s 100% of the time when a file is open
IME (Input Method Editor) isn’t the same thing as a mobile on-screen keyboard, though sometimes they can be on-screen keyboards (even on desktop). For instance, there are multiple ways to enter Japanese characters, and some OS IMEs can optionally bring up a little window to let users draw the symbols and then use handwriting recognition to figure out which symbol they drew.
You probably don’t want to be trying to implement all that yourself. So use SDL_Start/StopTextInput() and then get the UTF-8 characters from SDL_EVENT_TEXT_INPUT.
I would call SDL_StartTextInput() when your text area has focus, and call SDL_StopTextInput() when it loses focus.
It’s worth pointing out that, on desktop, using SDL_Start/StopTextInput() does not mean an on-screen keyboard or some other input method will be shown. Running SDL’s testime.c program doesn’t bring up any sort of on-screen anything on my US-English Mac.
You should read the Chat Box section of the Best Keyboard Practices article, if you haven’t already. It lays out the reasons why trying to build your own unicode input out of keypress events is a world of pain and will never work for every language out there.
And yes, my understanding is that for some languages you need to enter multiple keys to get a single unicode character.
Note that on desktop platforms SDL_EVENT_TEXT_INPUT is enabled by default, it’s not necessary to call SDL_StartTextInput(), indeed it’s the usual way of receiving keyboard input on such platforms.
On some platforms using this function shows the screen keyboard and/or activates an IME, which can prevent some key press events from being passed through.
It states here that “Text input is enabled by default on desktop platforms, and disabled by default on mobile platforms” and here that “On desktop platforms, SDL_StartTextInput is implicitly called on SDL video subsystem initialization which will cause SDL_TextInputEvent and SDL_TextEditingEvent to begin emitting”.
This is clearly the case in practice, because my app never calls SDL_StartTextInput() when running on a desktop platform yet it receives keyboard input from the SDL_EVENT_TEXT_INPUT events.
When SDL2 and SDL3 have identically-named functions, usually they also perform identically, or nearly so; it’s rare for such a major difference to exist (I’d be interested to know what the motivation was for this change).
The difference must frequently confuse people porting their apps from SDL2 to SDL3, when they find they aren’t receiving any keyboard input! Unfortunately I cannot use SDL3 myself, it doesn’t support the features my app needs.
Maybe its confusing but I think it isn’t. It seems like it’d be pretty obvious if a message completely stopped during a version change (which is more obvious than something that acts slightly differently) and the documentation is well written enough that it’s clear to use SDL_StartTextInput
But maybe I’m bias because I like to read documentation on version upgrades and when I deal with larger projects like the one I’m on now