Glfw: 输入法输入

输入法管理器

编辑了几次

仅供参考，截至当前 GLFW，使用 Microsoft IME 输入例如日语，在 IME 输入期间按下的键似乎通过常规 WM_KEYDOWN 消息直接到达应用程序。

我什至不知道是什么导致了这种情况，在我简单的 Win32 测试应用程序中，带有一个微不足道的消息循环，IME 正确地拦截了这些键。 我收到带有 VK_PROCESSKEY (229) 的 WM_KEYDOWN 和正常的未归档 WM_KEYUP。

在 GLFW 中，按下和释放的键值都未过滤。
我现在正在调查导致差异的原因，看看我是否可以建议修复 GLFW。

好的，现在发生的事情是，在我的应用程序中，我使用 wParam，它包含虚拟键代码并且可以通过 IME 过滤。 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 的支持。