许鹏飞

许鹏飞的博客

他的个人主页  他的博客

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

许鹏飞  2012年05月16日 星期三 22:17 | 2867次浏览 | 0条评论

这两天Gnome的开发列表里面很火热,关于输入法的事情吵的沸沸扬扬,具体细节还是去看list吧

http://mail.gnome.org/archives/desktop-devel-list/2012-May/thread.html

 

本文转载自 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要选择输入法自由的人还是洗洗睡了吧。

 

评论

我的评论:

发表评论

请 登录 后发表评论。还没有在Zeuux哲思注册吗?现在 注册 !

暂时没有评论

Zeuux © 2024

京ICP备05028076号