Glfw: IME input

Input Method Manager

edited a few times

FYI as of current GLFW, using Microsoft IME to input e.g. Japanese, the key pressed during IME inputs seems to reach the application directly via regular WM_KEYDOWN messages.

I don't even know what is causing this, in my simple Win32 test application with a trivial message loop the IME is intercepting those keys correctly. I receive WM_KEYDOWN with VK_PROCESSKEY (229) and normal unfiletred WM_KEYUP.

In GLFW I get unfiltered key values for both pressed and released.
I am now investigating what is causing the difference to see if I can suggest a fix for GLFW.

OK so what is happening is, in my application I am using wParam which contains virtual key-code and can be filtered by IME. GLFW in translateKey() uses HIWORD(lParam)&0x1FF which is scancode and is never filtered.

So when you press and release a letter key intercepted by IME, the sequence goes something like:

WM_KEYDOWN 229
13.36 Key 49 pressed
WM_KEYUP 78
13.43 Key 49 released

So to emulate something similar from a GLFW user point of view, it may be enough to add this to translateKey():

if (wParam == VK_PROCESSKEY)
    return _GLFW_KEY_INVALID;

Which will generate neither pressed neither released events.

Now the problem is that there so many possible ways to interpret the low-level data but I believe, and in spite of the fact that there is so much more to IME and this isn't the entire picture, that this behaviour would be the desirable default and very beneficial. The vast majority of applications don't want to react to key-presses when the IME window is displayed, which at least would allow IME-based text inputs into the application.

Application that strives to be 100% IME aware (down to implementing their own IME display), which is extremely extremely rare would have to handle many more messages in great details, which will probably never be the scope of GLFW (but one can imagine that GLFW may in the future provide WM_* hooks to allow the interested users to handle them themselves, and again there's no point in doing that work unless there's a really good reason to).

FYI I implemented support for IME via IBUS on X11/wayland in my glfw fork.