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

Open
elmindreda opened this Issue Jun 13, 2013 · 4 comments

Comments

Projects
None yet
4 participants
@elmindreda
Member

elmindreda commented Jun 13, 2013

No description provided.

@elmindreda

This comment has been minimized.

Member

elmindreda commented Jun 11, 2015

@ocornut

This comment has been minimized.

Contributor

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.

@ocornut

This comment has been minimized.

Contributor

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:

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

This comment has been minimized.

Contributor

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