KDE Plasma Wayland 下配置 Fcitx5:environment.d、KWin 与 XWayland
引言 在KDE Plasma从X11切换到Wayland后,Fcitx5输入法经常出现一种看似矛盾的状态: 问题的根源在于:Wayland、XWayland、Qt、GTK和XIM使用的输入法路径并不完全相同。 正确配置不应只是把所有变量都全局导出,而应明确每一条输入路径的用途。 一、原生Wayland输入法如何工作 在Wayland环境中,输入法通常通过Wayland输入法协议与合成器协作。 KDE Plasma中的合成器是KWin。 Fcitx5应在: 中启用。 这样KWin可以把Fcitx5作为Wayland输入法客户端启动,并为它提供需要的输入法协议连接。 这部分不是传统的XIM环境变量机制。 二、XWayland应用仍需要XMODIFIERS 旧X11应用运行在XWayland中时,通常仍然通过XIM与输入法通信。 因此需要: 注意模块名称是: 而不是: Fcitx5是程序的代际名称,但XIM和工具包模块使用的名字仍然是 fcitx。 三、为什么使用environment.d 推荐的用户级配置路径是: 例如创建: 内容: environment.d 是systemd提供的正式用户环境配置机制。 它适合Wayland桌面的原因包括: 修改后通常需要注销重新登录或重启,才能让新会话中的程序获得变量。 四、为什么不推荐全局设置GTK_IM_MODULE 传统配置经常包含: 这在X11环境中非常常见。 但在现代Wayland环境中,原生GTK应用可以通过Wayland输入法协议与Fcitx5配合。全局强制工具包模块,可能让原生Wayland应用绕过更合适的协议路径。 潜在问题包括: 因此,不应仅为了让变量“看起来完整”而全局设置。 五、为什么不推荐全局设置QT_IM_MODULE 同样,传统Qt配置常见: 但KDE原生Wayland应用通常应优先通过KWin和Wayland输入法协议工作。 全局强制 QT_IM_MODULE 可能导致: 更合理的原则是: 六、按应用设置兼容变量 某个旧Qt应用无法输入时,可以单独启动: 某个旧GTK应用无法输入时,可以使用: 如果应用通过桌面文件启动,可以复制相应 .desktop 文件到: 再修改 Exec=: 这样不会影响整个Wayland会话。 …