New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IME input #41

elmindreda opened this Issue Jun 13, 2013 · 4 comments


None yet
4 participants

elmindreda commented Jun 13, 2013

No description provided.


This comment has been minimized.


elmindreda commented Jun 11, 2015


This comment has been minimized.


ocornut commented Nov 29, 2015

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.


This comment has been minimized.


ocornut commented Nov 29, 2015

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:

13.36 Key 49 pressed
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).


This comment has been minimized.


kovidgoyal commented Jul 12, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment