WPS for Linux alpha试用

关于GNOME整合IBus事件的技术细节

Tiger Soldier posted @ 2012年5月16日 10:45 in linux with tags 输入法 gnome ibus , 14205 阅读

更新:本文乃根据过时的信息写成,其中绝大部分结论在现在已经完全不成立。请不要浪费时间阅读本文,也不要采纳任何结论。

 

 

=============我是过时的分隔线===============

 

 

 

这两天中文社区对于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要选择输入法自由的人还是洗洗睡了吧。

rediscover 说:
May 16, 2012 11:35:56 AM

Gsettings里强制设置GTK_IM_MODULE以后这个变量在session运行过程中不能修改,所以其他输入法不能使用。

Head_small
Tiger Soldier 说:
May 16, 2012 11:47:04 AM

@rediscover:
1. gnome-settings-daemon里设置的是XSetting属性gtk-im-module
2. 该变量只是被设置了默认值,可以随意修改
3. GTK_IM_MODULE是环境变量,不是gnome-settings-daemon设置的,而且这个环境变量的优先级大于XSetting的gtk-im-module属性

TualatriX 说:
May 16, 2012 12:06:38 PM

这篇文章才是应该发表在LinuxTOY上的嘛。

Head_small
Tiger Soldier 说:
May 16, 2012 12:11:01 PM

LinuxToy上的大部分人应该看不懂,他们只要结论就够了

Avatar_small
依云 说:
May 16, 2012 12:50:33 PM

「在用户没有干预的情况下,启动IBus后,IBus将被设置为默认输入法。」「对其他输入法用户而言,一切照旧,就当这个特性没有存在过。」也就是说,用户无法以其它输入为主、需要时启动 ibus 了?

「第二项正是打包者喜闻乐见的。不希望GNOME依赖IBus?把IBus集成开关关掉就好。将IBus集成关闭后,除了不会自动把IBus设置为默认输入法外,没有任何不良影响。」——除非是 Gentoo 用户,否则像我明明已经有了 wicd 却被 empathy 的依赖强制安装上个无用的 NetworkManager 的事情还会继续。由此推广下去,在将来,一个可能的情况是,即使你只用 GNOME 的一个微小的组件(甚至你只是想写写 GTK 程序),你都必须安装整个 GNOME 环境。

另外一个可以预见的情况是,「什么?使用输入法有bug?这种情况在ibus下能重现吗?不能?那抱歉,你去给那输入法的开发者报bug吧!」(Cf https://bugzilla.gnome.org/show_bug.cgi?id=675014#c2 and https://bugzilla.gnome.org/show_bug.cgi?id=675011#c3 )

Head_small
Tiger Soldier 说:
May 16, 2012 01:00:20 PM

1. 我已经指出,传统的使用环境变量指定默认输入法的方法依然有效。我不明白你要通过什么方法实现“以其它输入为主、需要时启动 ibus”,所以我目前无法提供答案

2.这个是GNOME的依赖,和GTK无关。至于empathy、networkmanager的事,我只能很遗憾地说,估计还会发生。但要指出的是,这是GNOME环境的依赖,而不是GNOME组件的依赖。GNOME的大部分程序是可以脱离GNOME环境运行的

3.我认为这是正常的流程

alpha080 说:
May 16, 2012 01:03:20 PM

我觉得还是应该发过去,看不懂跟看到之后还是有区别的。
toy上面那篇文章太随意了,而且大多数人不会去查看邮件列表,惭愧的是我也是其中一员,只看了几篇,但是输入法的运行机制实在是不太清楚,只好选择相信@csslayer.

Houge_Langley 说:
May 16, 2012 01:23:30 PM

其实我也是只需要结论足以的用户。

看了结论其实所有用户都可以更加放心了,大家不用为不能使用其他输入法而纠结

csslayer 说:
May 16, 2012 02:03:26 PM

首先我在所有提及那个提交的地方都表示是“可能影响”。因为我个人在浏览了几个代码库之后并没发现具体使用那个值的地方,(而且话说这个应该是非标准值,怎么牵扯上gtk的我也暂时不明)我只是表达了对使用这个值的情况的担忧。

其次另外的一个目的是希望即使支持ibus也使用一个可以在“运行时”drop的依赖,在相关修改的几个repo当中唯一受到影响的g-s-d,目前采用的是一个编译开关的形式,这里ibus的开发者后来出现之后表示会可能会采用额外加载library的方式。

如果用archlinux的话,基本就是optdepends和depends的差别(因为arch一般还是采用开所有可能的开关以保证feature)。

csslayer 说:
May 16, 2012 02:06:40 PM

其他部分由于都是运行时检测我在邮件列表也表示无所谓。ibus-gjs究竟是放到gs里面还是外面其实我根本不在乎。

Avatar_small
依云 说:
May 16, 2012 02:18:24 PM

1. 在使用其它输入法时启动 ibus,并在 GTK 菜单中选择 ibus 而不是默认输入法。「在用户没有干预的情况下,启动IBus后,IBus将被设置为默认输入法。」不是说这时候 ibus 会变成默认的么?

2. 「GNOME的大部分程序是可以脱离GNOME环境运行的」,事实是,empathy 和 gnome-terminal 已经因为无法在我的非 GNOME 环境下运行而不得不抛弃了。我不知道下一次又会是什么 GNOME 组件里的程序会出问题。如果 GNOME 他们不改变的话,你的「大部分」持续不了多久了。

3. 我认为这是封闭的表现。

csslayer 说:
May 16, 2012 02:30:57 PM

关于“非标准值”认识主要是那个GSettings的namespace是org.gnome的,所以是否直接会转换成XSettings这点是不知道了,当然也许你比我了解你可以解释一下。这点直接在gnome的list上问也比较快。因为我至今其实无法确认那段代码和你列举的文档代表是同一个设置。而事实上gnome也在将xsettings移植到gsettings

当然不如说直接得到gnome开发者的确认比较有用。(事实上目前已经得到了)

csslayer 说:
May 16, 2012 02:34:02 PM

要我说的话目前的结果是
1、继续用别的输入法框架大概是没问题的
2、选项开启后的编译后依赖可能变成运行时的也可能不,这取决于他们自身的决定。

Head_small
Tiger Soldier 说:
May 16, 2012 02:49:20 PM

1. 没问题,因为你要使用IBus之外的输入法作为主输入法时已经进行了“用户干预”了

2. 我前不久才在KDE下用过empathy和gnome-terminal,所以我不确定你的是什么问题

3. 如果是GNOME本身的bug,哪怕IBus不会触发,GNOME开发者也会处理的。但是如果是fcitx的bug,扔给fcitx不是正常流程么

Head_small
Tiger Soldier 说:
May 16, 2012 02:52:52 PM

我觉得你可能还是得在乎一下,比如今后kimpanel是否要屏蔽keyboard图标,candidata panel是否要采用系统自带的等等

csslayer 说:
May 16, 2012 02:54:47 PM

2、他用awesome,gnome-terminal获得焦点的行为不正确(输入法无关的一个问题)
gnome的开发者表示他们不会处理。所以让仙子很伤心,尽管在我看来可以理解,虽然对某些人来说确实不可接受。

3、这点我表示没什么问题,发给fcitx的话我们也比汇报bug的人本身更能了解出现了什么问题,之后再返回汇报个gnome也会更加有效率。我在这篇bug里面想要表达的意思就是这个。
https://www.csslayer.info/wordpress/fcitx-dev/fix-input-method-support-in-linux-world/

csslayer 说:
May 16, 2012 02:56:44 PM

这点是几乎不可能的,candidate panel使用的是ibus自己的协议。

图标的话可能会考虑不过也得看他们做成什么样子了

Head_small
Tiger Soldier 说:
May 16, 2012 02:59:35 PM

你这么一说我还真没留意,看一下文档再说

Avatar_small
依云 说:
May 16, 2012 03:23:59 PM

2. 没关系,说不定过几个月它们俩在 KDE 下也会出问题了。然后你是给 KDE 报 bug 呢还是给出问题的软件报 bug?

csslayer 说:
May 16, 2012 03:27:23 PM

我们的目的不是开gnome批判会……(以及事实gnome-terminal上早就在KDE出问题了,不过具体来说是个窗口大小策略不同的问题,gnome-terminal在kwin下已打开就会自己动画般的缩到最小)

当然用户自己其实也很懒,有替代品的话也不会去太报bug或者怎么样的……

Head_small
Tiger Soldier 说:
May 16, 2012 03:50:35 PM

那这就应该是这两个货的问题了,如果KDE的人管这个那就是雷锋了

Head_small
Tiger Soldier 说:
May 16, 2012 03:53:24 PM

candidate panel的代码我全碰过一遍,如果他们没有大改的话,candidate panel本身只定义了candidate UI相关的接口,IBus部分是在另一个叫ibuspanel还是什么的地方完成的

当然不知道现在改成什么样子了,不过现在candidate panel没有import ibus相关的库,可能并没有引入ibus依赖

csslayer 说:
May 16, 2012 03:59:02 PM

你知道……当api不在自己这边(尤其是没有clare 保证稳定的情况下)风险还是存在的。

另外老实讲,不一定完全能work在一起。还是自立好一点。比较自由。尤其是老版本还没这个api,写两套兼容不是什么好点子,fork都是一个更好的选择

Head_small
Tiger Soldier 说:
May 16, 2012 04:48:13 PM

也对,而且特性不一定兼容

Mike 说:
May 16, 2012 11:23:26 PM

要是 GNOME 的 iBus 集成能真的好一点,我也就安心用 iBus 好了,问题是不稳定啊,动不动不能输入的,switcher 弱到爆,速度慢……能改正这些常常被我吐槽的缺陷,继续 iBus 无误。

Head_small
Tiger Soldier 说:
May 16, 2012 11:50:59 PM

这个就不关集成的事了,真是ibus的问题。切换输入法慢是因为每个引擎都是一个独立程序,第一次切换的时候需要启动之,当然会慢了。第二次切换就会快很多。

Mike 说:
May 17, 2012 12:48:40 PM

其实我想吐槽的是GNOME集成了一个不好用的iBus。如果 iBus 好用,我绝对全力支持,因为可以基本上统一一下输入法平台,收拾一下现在乱七八糟的局面

Avatar_small
依云 说:
May 17, 2012 01:42:06 PM

整合一个输入法到 GNOME 就能统一输入法平台?你是当 GNOME 是 Linux 呢还是类 Unix 呢还是一切 OS?

Head_small
Tiger Soldier 说:
May 17, 2012 04:05:48 PM

整合ibus是有原因的,其中一点是ibus的维护者大多在Red Hat。

ibus的开发者和GNOME开发者配合得很紧密,很多工作是从3.0开始就在做了的,所以不选ibus才怪呢

gcc 说:
May 17, 2012 09:47:49 PM

LinuxToy读者水平比以前下降得这么厉害?

Avatar_small
依云 说:
Aug 22, 2013 12:59:14 PM

在给不少 GNOMEE 3 用户贴了近十次这个链接 ( https://fcitx-im.org/wiki/Note_for_GNOME_Later_than_3.6 ),我表示,「对其他输入法用户而言,一切照旧,就当这个特性没有存在过」,照你妹啊!

jack 说:
Nov 08, 2013 10:32:52 AM

我是搜怎么在gnome里停止ibus自启动来到这篇文章的。现在的情况是,我的gtk_im_module设置的是fcitx,fcitx在gnome的自启动里面,但是每次开机的时候ibus的进程先启动,fcitx就起不来了。所以没法用,难道用户干预指的就是每次先手动干掉ibus,再启动自己用的输入法框架?完全是gnome的脑残行为。


登录 *


loading captcha image...
(输入验证码)
or Ctrl+Enter