[转载]关于GNOME整合IBus事件的技术细节

本文转载自 http://tigersoldier.is-programmer.com/2012/5/16/tech-detail-about-gnome-ibus-integration-feature.33657.html

未经授权

  这两天中文社区对于GNOME 3.6计划中的IBus/XKB整合特性提 出了异议。在没有充分了解技术细节的情况下爆发了所谓“圣战”。许多人在根本不知道是什么回事的情况下认为GNOME此举将导致自己无法自由更换输入法， 并表示严重抗议。为此我草草查阅了一下该特性相关的技术细节，并给出我的结论。由于我不是输入法开发者，有些技术细节可能是我理解错误，发现了请指出。

先说结论

为了迎合那些没有耐心看长文的人，我先说出我的结论：GNOME对IBus的整合不会影响选择其他输入法的自由，也不会强制安装IBus。

以下是具体分析。要说明的是，本文所指的“输入法”均是指输入法框架而不是输入法引擎。

整合什么东西

在GNOME的特性描述页面中 明确指出：“Integrate the IBus input method framework into the shell input menu and in the control-center region panel. ”也就是说，主要是两方面的整合：

1. 将输入界面整合到GNOME Shell中；
2. 将设置界面整合到GNOME系统设置的区域与语言设置中。

在这里，没有提到要绑定iBus作为GNOME基本组件的一部分，反而有这么一句话：“... the experience should be the same whether IBus is being used or just plain XKB. ”在设计时已经考虑到了iBus不存在的情况，强制使用IBus根本无从说起。

将IBus强制设置为默认法

在所有的担忧中，从技术上来说最靠谱的是@csslayer提出的gnome-settings-daemon的一个改动。这个改动的霸道之处在于以下几点：

1. 如果编译时IBus已安装，会加入libibus依赖；
2. 如果加入libibus依赖，IBus将在输入设备生效时变成默认的IM Module；
3. 如果加入libibus依赖，但是IBus没有启动，则默认IM Module将自动变成gtk-im-context-simple。

表面上看来，只要IBus依赖被编译，用户只能在IBus和完全无用的gtk-im-context-simple中二选一了？

并非如此。

在这里简单介绍一下IM Module。在输入法工作流程中，正常情况下是这样的（注意是正常情况，在实际中现代输入法都使用了snooper，流程与此不同，但不影响讨论结果）：

1. 输入框接收到按键事件；
2. 输入框将按键事件转发给输入法；
3. 输入法处理按键事件；
4. 输入法将结果转发回输入框。

这里需要输入框与输入法的交互。但是，输入框如何知道你使用的是哪个输入法，又如何与输入法传递消息呢？GTK对输入法定义了一系列的交互接口，大部分输 入法都实现了这个接口，并编译成一个动态链接库。每个输入法的这么一个动态链接库就是一个IM Module。因此，选择了某个IM Module，就选择了将按键事件发送到对应的输入法中。

那么，如何选择IM Module呢？GTK文档中指出了两种方法：设置GtkSetting中的gtk-im-module属性，或者设置GTK_IM_MODULE环境变量。在gnome-settings-daemon的改动中，使用的是设置gtk-im-module属性的方法。GTK的另一篇文档则表示，如果设置了GTK_IM_MODULE环境变量，该环境变量将覆盖gtk-im-module属性的值。也就是说，尽管gnome-settings-daemon将默认输入法为IBus，我们也可以使用GTK_IM_MODULE环境变量修改默认输入法，而大多数发行版正是使用这种方法来设置默认输入法的。

因此，这项改动不会影响输入法的选择权。

将IBus作为安装依赖

目前一部分打包者担心GNOME集成IBus后，GNOME会依赖IBus，无法在保留GNOME的前提下将IBus从系统中移除。

从上节提到的gnome-settings-daemon的改动上来看，如果编译时打开了IBus集成选项，确实会依赖IBus。但是：

1. GNOME只依赖libibus，并不依赖整个IBus；
2. 可以通过编译开关关闭IBus集成（--enable-ibus）。

第二项正是打包者喜闻乐见的。不希望GNOME依赖IBus？把IBus集成开关关掉就好。将IBus集成关闭后，除了不会自动把IBus设置为默认输入法外，没有任何不良影响。

如果打包者把IBus集成打开，然后洁癖控不干了，那么gentoo欢迎你（这年头，不用gentoo都不好意思说自己是洁癖控）。

除了gnome-settings-daemon，我所能找到的与IBus相关的地方有两个：gnome-control-center和gnome-shell。其中，gnome-control-center一度引入了强制的IBus依赖，但是后来又将IBus依赖完全去除了。至于gnome-shell部分，主要是原来的ibus-gjs的UI代码移入了gnome-shell。ibus-gjs的代码是依赖于libibus的（废话），但是移入gnome-shell的部分会自动判断IBus是否存在，而没有引入强制依赖。

至此可以得出结论：GNOME对IBus的整合确实会引入对IBus的依赖，但是IBus依赖可以通过编译开关去除，并且去除IBus依赖后，对安装了IBus的人来说，GNOME与IBus的集成功能依然存在。

这项整合的真正影响是什么

简单来说，就是IBus变成了GNOME的一等公民。具体体现在以下几个方面：

1. GNOME Shell为IBus保留了UI；
2. GNOME设置中心可以在区域与语言设置中对IBus进行设置；
3. 在用户没有干预的情况下，启动IBus后，IBus将被设置为默认输入法。

也就是说，GNOME在用户交互上会与IBus保持深入合作。

对于不使用IBus的用户而言，这意味着：

1. 只要不启动IBus，GNOME的一切集成都没有可见的效果；
2. 可以使用输入法自带的配置工具进行输入法配置，而这个配置工具从技术上来说是可以集成到GNOME的设置中心的；
3. 需要通过环境变量将自己使用的输入法设为默认输入法（别抱怨，我们一直都是这么做的）。

总结起来就是两点：

1. IBus用户可以在GNOME中得到良好的开箱即用体验；
2. 对其他输入法用户而言，一切照旧，就当这个特性没有存在过。

总结

本文试图通过我所了解的信息，总结出GNOME 3.6的IBus集成特性对IBus和其他输入法用户的影响。本文所得出的结论基于我所观察到的事实。如果我的观察有错误，欢迎指出，我将视错误的严重程度修改我的观点。

目前我的观点是：这项特性只会方便使用IBus的用户，对不使用IBus的用户没有太大影响。那些吵着向GNOME要选择输入法自由的人还是洗洗睡了吧。