Glfw: IME入力

インプットメソッドマネージャー

数回編集

参考までに、現在のGLFWの時点では、Microsoft IMEを使用して日本語などを入力していますが、IME入力中に押されたキーは、通常のWM_KEYDOWNメッセージを介してアプリケーションに直接到達しているようです。

何が原因なのかさえわかりません。簡単なメッセージループを使用した単純なWin32テストアプリケーションでは、IMEがこれらのキーを正しくインターセプトしています。 VK_PROCESSKEY（229）と通常のファイルされていないWM_KEYUPでWM_KEYDOWNを受け取ります。

GLFWでは、押された状態と離された状態の両方で、フィルタリングされていないキー値を取得します。
現在、違いの原因を調査して、GLFWの修正を提案できるかどうかを確認しています。

さて、何が起こっているのかというと、私のアプリケーションでは、仮想キーコードを含み、IMEでフィルタリングできるwParamを使用しています。 translateKey（）のGLFWは、スキャンコードであり、フィルタリングされないHIWORD（lParam）＆0x1FFを使用します。

したがって、IMEによってインターセプトされた文字キーを押して放すと、シーケンスは次のようになります。

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

したがって、GLFWユーザーの観点から同様のものをエミュレートするには、これをtranslateKey（）に追加するだけで十分な場合があります。

if (wParam == VK_PROCESSKEY)
    return _GLFW_KEY_INVALID;

これは、押されたイベントも解放されたイベントも生成しません。

ここで問題となるのは、低レベルのデータを解釈する方法がたくさんあるということですが、IMEにはまだまだ多くのことがあり、これが全体像ではないにもかかわらず、この動作は望ましいデフォルトで非常に有益です。 大多数のアプリケーションは、IMEウィンドウが表示されているときにキーが押されたことに反応することを望んでいません。これにより、少なくともアプリケーションへのIMEベースのテキスト入力が可能になります。

非常にまれな100％IME認識（独自のIME表示の実装まで）を目指すアプリケーションは、さらに多くのメッセージを詳細に処理する必要があり、おそらくGLFWの範囲にはなりません（ただし、想像できます） GLFWは、将来、関心のあるユーザーがそれらを自分で処理できるようにするWM_ *フックを提供する可能性があります。また、本当に正当な理由がない限り、その作業を行う意味はありません）。

参考までに、glfwフォークのX11 / waylandでIBUSを介してIMEのサポートを実装しました。