IME input

[elmindreda]

No description provided.

[elmindreda]

Input Method Manager

[ocornut]

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.

[ocornut]

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).

[kovidgoyal]

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

[JakkuSakura]

Any progress, especially fcitx?

[mei-rune]

can fix it soon!

Chinese input method not supported on linux xorg desktop

[JakkuSakura]

There is some progress. Kitty terminal implemented GLFW ibus support, but no fcits. However, fctix5 can emulate fctix4 and ibus frontend, and it works on Kitty

[XLPhere]

Hi I've been trying to get it to work with fcitx 5 (Xorg/KDE/GLFW 3.3.3) i am getting the IM-box and can type there but i don't get proper events that inform me of that - I'm using glfwSetCharModsCallback, is there maybe another event i have to get besides of the char-mods-callback?

[philipguin]

Hey, is there a way to move the IME to an arbitrary place on screen? Right now in my game engine it just hangs in the top-left, would really prefer to set it's location explicitly. Really appreciate this feature though!

[ashie]

We implemented IME support for each platform in #2130