SDL 2.0.4 text input mode on OSX |
Trevor Powell
|
When text input mode is turned on and I use OSX's "accent menu" (which is actually a popup floating window); I don't seem to be getting the SDL_TEXTEDITING events I expect. Instead, I just get extra SDL_TEXTINPUT events for accented characters chosen from the "accent menu" window.
Ordinarily on OSX, when typing an 'à ' into an SDL application, I would expect the following steps to happen: 1. Press and hold 'a' (SDL_TEXTINPUT event with text 'a', text display shows: 'a') 2. Accent menu opens (no SDL event, text display still shows: 'a') 3. Press '1' to select the accent from the menu (SDL_TEXTEDITING event with string 'à ', text display now shows: 'à ') Steps 1 and 2 work as expected. But during step 3, I get a second SDL_TEXTINPUT event with the accented character 'à ', instead of an SDL_TEXTEDITING event with the replaced character. This results in the text display being 'aà ', since it's not replacing the original pre-accent glyph. Has anybody had success with using text input mode on OSX? Might I be missing something obvious, here? I can have a bit of a rummage around in the code to see if I can figure out what's going wrong, if not. But thought I'd check first just to make sure that I'm not doing something obvious and silly. (Side-note: I note that SDL appears to start up with text input mode turned on; I would have expected it to begin disabled, and not turn on until I call SDL_StartTextInput(). Verified on OSX and Linux, and I assume the same behaviour is true on Windows. The wiki's tutorial on text input mode also seems to assume that text input mode starts out disabled.) |
|||||||||||
|
Trevor Powell
|
Okay, results of investigation:
Under the cocoa implementation of the text entry stuff (inside SDL_cocoakeyboard.m), we use an implementation of Cocoa's NSTextInputClient protocol to interact with OSX's native text editing facilities. Turns out that OSX's accent menu isn't going through IME at all; it's just sending `insertText:replacementRange:` messages, exactly like normal text input, but it specifies a different 'replacementRange' value when you're using the accent menu than when you're entering text normally. Normally, text entered gives us a (location,length) value of `(-1,0)`. Text entered via the accent menu instead gives us a value of `(0,0)`. So what we really need to do in the case of OSX accent menu usage, I think, is have some way to tell the linked application that the previous character needs to be replaced with the new character, rather than appending the new character. And there isn't an obvious way to do that under our current API.. I guess I could send a keydown and keyup to simulate a backspace event, and hope that the application does the right thing. Or perhaps we could add a "replace" or "overwrite" flag to the SDL_TextInputEvent which, if set, would indicate that the provided UTF8 text should replace the previous UTF8 codepoint, instead of being appended after it. Or maybe it would be better to create an entirely different event type. ("SDL_TextReplaceEvent", perhaps?) Anybody have thoughts/opinions/preferences? I'm sort of leaning toward the 'overwrite' flag, personally, but am open to other points of view. |
|||||||||||
|
SDL 2.0.4 text input mode on OSX |
Jonny D
|
I'm not very experienced with these things, but I sort of expected that holding the 'a' key to open the accent menu would start a composition by sending an SDL_TEXTEDITING event for temporary display. Then when you complete the composition with an accent, the result would be sent through an SDL_TEXTINPUT event.
It seems like that's what is supposed to happen according to: https://wiki.libsdl.org/Tutorials/TextInput Jonny D On Friday, March 25, 2016, Trevor Powell wrote:
|
|||||||||||||
|
SDL 2.0.4 text input mode on OSX |
Re: SDL 2.0.4 text input mode on OSX |
Trevor Powell
|
You need to be running OSX Mountain Lion (10. or later, be using an English keyboard, have SDL's text input mode turned on, and not have disabled the accent menu system-wide. Apart from SDL's text input mode, all the other factors will also disable the accent menu in all other locations in OS X. So if you don't get the accent menu in (for example) TextEdit, you won't get it in SDL applications either. The accent menu can be disabled on a system-wide basis using the terminal command: `defaults write -g ApplePressAndHoldEnabled -bool false`, and then later be re-enabled by using `defaults write -g ApplePressAndHoldEnabled -bool true`. If you're not getting the accent menu, you may have disabled it; lots and lots of users did exactly that as soon as it was introduced, precisely because it broke key repeat for accent menu-triggering keys. |
|||||||||||||
|
SDL 2.0.4 text input mode on OSX |
Alex Szpakowski
Guest
|
I’m running OS X 10.11.4 with an American english keyboard and the U.S. input source. I do get the accent menu in most other programs – for example in Apple’s Mail.app, which I’m using to write this.
|
|||||||||||||
|
Re: SDL 2.0.4 text input mode on OSX |
Trevor Powell
|
I absolutely agree with you (in fact, my first post to this thread said almost exactly the same thing). However after investigating, it seems that OSX considers the accent menu to be different from compositions (which in cocoa seem to be referred to as 'marked text'; just in case somebody else wants to look over the relevant protocols to verify what's going on). With accented characters entered via the accent menu, OSX definitely doesn't initiate marked text at all; it just sends an "insertText" message with the initially pressed character before the accent menu opens, and then another "insertText" message with the accented version of the character, with a "replacementRange" value which apparently is intended to indicate that this latest character should replace the previous character, whatever it might have been. We don't seem to get any other messages from OSX with which to determine that this latter 'insertText' message has come from the accent menu, or that the earlier one ever made the accent menu show up. And since we don't have a start or an end notification, we can't even fake it and shoehorn this into the SDL_TEXTEDITING event path; it's just something that could happen at any time, without our knowledge. We don't even appear to be able to tell OS X to disable its display of the accent menu, without disabling support for text compositions entirely. The only option I can see is to just set it up so that SDL's Text Input event can cope with this thing that OS X wants to be able to do via its 'InsertText' message. Though obviously I'd be thrilled if anyone can see an alternative! |
|||||||||||||
|
Re: SDL 2.0.4 text input mode on OSX (resolved) |
Trevor Powell
|
After a bunch of testing with the kind help of Alex Szpakowski, we've pretty well established that SDL2 applications normally will never invoke the accent menu on OS X, regardless of build settings, library type (framework vs. shared libs vs. static), deployment targets, or varying build toolchains.
The problem turned out to have been that as I migrated my project from SDL1.2 to SDL2, I had left SDLMain.m in place for the OS X builds (the migration guide refers to SDL_main as "optional"). But in practice, the operations performed in that SDLMain.m source file from SDL1.2 accidentally enables the accent menu, under SDL2. (They also cause SDL2 applications to open in the background, when the app isn't being launched by the Finder, and are likely to cause other problems as well.) It may be worth inserting some stronger language into the migration guide about the importance of removing SDLMain.m from legacy projects, but there's no need for any code modifications to SDL2 like those I had been suggesting earlier. All is good! |
|||||||||||
|
SDL 2.0.4 text input mode on OSX |
Alex Szpakowski
Guest
|
Interesting – I wonder what the specific thing that SDLmain does (and SDL2’s OS X backend code doesn’t do) which makes the accent menu appear.
|
|||||||||||||
|
Re: SDL 2.0.4 text input mode on OSX |
Trevor Powell
|
I tried removing individual bits of functionality from the file's`SDLMain` NSApp delegate, but couldn't find a specific culprit. Removing the functionality around setting up the menubar, the application/window menus, and around configuring the working path, all could be disabled and the accent menu would still appear. I don't see any other bits of functionality in that code that I could disable, without completely disabling the whole app delegate structure, so I'm assuming that maybe that's what the problem is; maybe something new is expected on an NSApp delegate to specify whether an application supports the accent menu, and that's just missing from the old SDLMain.m implementation? I don't know. It's all moot, I guess; `SDLmain.m` simply should no longer be used in OS X builds. It isn't even included in the current SDL2 distributions; it was only in my project because I'd upgraded from SDL1.2 and hadn't noticed that the file had gone away, and the migration docs didn't say to remove it. |
|||||||||||||
|
SDL 2.0.4 text input mode on OSX |
Eric Wing
Guest
|
On 3/31/16, Trevor Powell wrote:
I have vague memories about NSPrincipleClass. If I recall, most Cocoa apps rely on this to do the normal application start up. I think SDL bypasses this entirely. However, the old SDLmain might have done something with this since it was also bringing back proper menus and such. -Eric _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|