Open heiher opened 6 months ago
在Arch Linux的GNOME Shell桌面环境上,GNOME版本是45,窗口系统是Wayland。切换至IBus Rime引擎的中文输入模式,当按下大写锁定键后,输入法切换至了英文输入模式,且大写锁定指示灯亮起,此时输入字母却仍为小写。
该问题在操作系统软件包某次升级后出现,具体是哪个软件包暂时没有时间排查,但通过版本回退实验可以确定的不是ibus-rime和librime。高度怀疑是GNOME桌面环境的某个软件包。
ibus-rime
librime
通过修改 ibus-rime 源代码实验,发现在中文输入模式按下大写锁定后,IBusRimeEngine的process_key_event接收到的keyval已是大写键值,但应用输入框接收显示出来的却仍是小写。在process_key_event函数中还发现如果被rime处理掉的按键事件会返回TRUE,这应该意味着该按键事件不再继续向后传递。有了一个猜测:是因为这个原因导致了后续的节点没有感知到大写锁定的按键事件。于是就有了以下的补丁:即使Rime处理了大写锁定事件,也返回FALSE使其继续向后传递。下面的补丁可以解决上述问题。
process_key_event
keyval
TRUE
FALSE
https://github.com/heiher/ibus-rime/commit/b609cf077f478a9c0a968390adc91ccf88bc3c9d
diff --git a/rime_engine.c b/rime_engine.c index 4e08960..ddb74a2 100644 --- a/rime_engine.c +++ b/rime_engine.c @@ -523,6 +523,9 @@ ibus_rime_engine_process_key_event (IBusEngine *engine, gboolean result = rime_api->process_key(rime_engine->session_id, keyval, modifiers); ibus_rime_engine_update(rime_engine); + if (keyval == IBUS_KEY_Caps_Lock) { + return FALSE; + } return result; }
考虑到librime应该还可以支持自定义大写锁定的行为,可能好的方法是使rime process_key在恰当的情况下返回FALSE? 或问题的根因还是在图形栈中?算是抛砖引玉吧。
在Arch Linux的GNOME Shell桌面环境上,GNOME版本是45,窗口系统是Wayland。切换至IBus Rime引擎的中文输入模式,当按下大写锁定键后,输入法切换至了英文输入模式,且大写锁定指示灯亮起,此时输入字母却仍为小写。
该问题在操作系统软件包某次升级后出现,具体是哪个软件包暂时没有时间排查,但通过版本回退实验可以确定的不是
ibus-rime
和librime
。高度怀疑是GNOME桌面环境的某个软件包。通过修改 ibus-rime 源代码实验,发现在中文输入模式按下大写锁定后,IBusRimeEngine的
process_key_event
接收到的keyval
已是大写键值,但应用输入框接收显示出来的却仍是小写。在process_key_event
函数中还发现如果被rime处理掉的按键事件会返回TRUE
,这应该意味着该按键事件不再继续向后传递。有了一个猜测:是因为这个原因导致了后续的节点没有感知到大写锁定的按键事件。于是就有了以下的补丁:即使Rime处理了大写锁定事件,也返回FALSE
使其继续向后传递。下面的补丁可以解决上述问题。https://github.com/heiher/ibus-rime/commit/b609cf077f478a9c0a968390adc91ccf88bc3c9d
考虑到librime应该还可以支持自定义大写锁定的行为,可能好的方法是使rime process_key在恰当的情况下返回FALSE? 或问题的根因还是在图形栈中?算是抛砖引玉吧。