Umlauts input on OS X

Hello everyone,
on Mac OS X, users can type Umlauts (e.g. ä), using option/alt + u to create the diaeresis ( ¨ ) and then the character they want the umlaut of, e.g. a. The text on moving from GLFW 2 to 3 said:

However, many keyboard layouts require more than one key to produce characters with diacritical marks. Even the Swedish keyboard layout requires this for uncommon cases like ü.

And the input guide says:

Unlike key input, text input obeys keyboard layouts and modifier keys and supports composing characters using dead keys.

So I expected this to work using glfwSetCharCallback, but option+u yields nothing and the following character is reported unaltered: instead of ä I get a.
Is this the intended behavior? Shouldn’t option+u return U+0308 (COMBINING DIAERESIS) to the character callback on OS X (when using the U.S. keyboard layout)? Is there any portable way to get text input using GLFW like I’d get it in a native text field?

This sounds like a possible bug or missing feature. It may be a missing feature because the glfw documentation is referring to standard unicode input where the user presses a number of keys together at once to produce a unicode character. This method you mention has the user pressing two keys at once, releasing, then pressing another key.

I don’t personally know if this input method is supported under OS X. The standard unicode multi-key approach is though.

The CharCallback should only receive unicode characters, so if this input method was to be supported Option+U followed by a should result in ä which is U+00E4. The Option+U should be ignored, but the next key press should be translated.

I’d recommend trying the latest code on Githhub, and if this issue persists filling an issue.

I’ve just tested this with latest and it works fine - the test app events on OS X 10.10 calls the char callback with 0x000000e4 which is ä after pressing Option+u then a.

So it looks like you need to use a newer version of glfw.

True, it works. The system-wide installed version reports to be 3.1.2, so I figured it’s current enough. I guess it might’ve been compiled with some odd parameters. Anyway, sorry for not trying the latest version from git first and thank you for the help!

1 Like

Seems 3.1.2 was released 2015-10-12 and what looks like the fix was 2015-11-13, and I found the corresponding issue #456