为什么Linux下的输入法如此Fxxk

这里不是用来讨论实际算法上的问题的,而是说明一些兼容性的问题。例如你想说输入法不够智能什么的还请不用期待了,这不是本文的关注对象。

先来说说安装问题,众所周知的,输入法安装之后,往往都会提到以下三个环境变量:XMODIFIERS,GTK_IM_MODULE,QT_IM_MODULE。这三个货都是干什么的?为什么要设置这三个货?为什么Linux输入法用起来这么不方便?

这就得从头说起。

首先是XIM协议。更加详细的说明请参考这里:http://www.ibm.com/developerworks/cn/linux/i18n/xim/xim-2/index.html

所有的X程序都应当可以采用XIM作为输入法的协议,这和Qt还是GTK没有关系(X上的Qt和GTK,当然和Windows上的就没什么关系了)。这个协议简单说来就是会把按键事件先交给XIM Server,XIM Server做对应的处理,然后按照处理结果,将输入结果或者按键再交给对应的应用程序。

这里就要提到XMODIFIERS这个东西了,一般来讲,都会设置成@im=xim server name这个值。也就是说,如果XIM Server有多个,那么你可以根据这个变量来指定某个程序是使用这个XIM Server或者哪个XIM Server。这也就是比如fcitx为什么运行两个的时候会提示有同名的XIM Server在运行,是的,这个名称不可重复。

但是Qt和GTK其实都不喜欢这个东西,因为如果需要跨平台的话,这个XServer Only的东西其实说起来并不是那么好使。于是就出现了IM Module这个东西。这个是什么呢?那就是用来处理IM信息的模块,原则上来说替代了XIM的协议,使得按键信息实际上是交给这个模块,然后再交给IM Server(注意已经不是XIM了)。那么如何支持原来的XIM呢?于是Qt和GTK实际上都自带了一个IM Module,这个module负责将它收到的再通过XIM协议和XIM Server通信。

看起来一切都非常美好?我们来说几个常见问题。

1、光标跟随

这个问题不能怪任何一个输入法,事实上由于IM Server负责显示输入框,光标的位置是由应用程序告诉我们的。它不告诉我们输入框在哪,自然也就不能光标跟随。

2、BackSpace按键删除的不是候选输入的文字

例如pidgin的状态吧,大致上,因为这里pidgin为了用户体验,设计了一个键盘的图标,按键时就会让这个图标变化,于是它需要抓取键盘按键,不幸的是它把BackSpace抓走了,于是输入法没有收到BackSpace键,那么自然也不会做应该做的事情。

3、非纯粹的GTK和Qt程序下的问题

比如Firefox,Flash,OpenOffice,Opera。他们在im module上面又包了一层,又或者是自己处理,于是就会出现更加奇妙的问题。

4、非CJK Locale无法输入

我们来看看gtk-query-immodules-2.0的执行结果,以scim和xim为例子,ibus搞了个workaround避过了这个问题。

“/usr/lib/gtk-2.0/immodules/im-scim.so”

“scim” “SCIM Input Method” “scim” “/usr/share/locale” “ja:ko:zh”

“/usr/lib/gtk-2.0/2.10.0/immodules/im-xim.so”

“xim” “X Input Method” “gtk20” “/usr/share/locale” “ko:ja:th:zh”

什么情况呢?意思就是说明scim和xim是要在ko,ja,th,zh这几个locale下面用的,其他情况我不默认选择xim。

好了,en_US等locale无法输入的问题根源就是这个,gtk不会默认用的,那怎么整?可以靠GTK_IM_MODULE这个环境变量强制指定,或者在/etc/gtk-2.0/gtk.immodules(那个命令负责生成这个文件,但是实际用的时候还是都这个文件),加上”en:”。ibus的imdule的值是:”ko:ja:th:zh:*”,所以大概避免过了这个问题。还有一些说法是设置LC_CTYPE为”zh_CN.UTF-8″。实际上是把自己伪装成了zh,也没问题。

接下来顺便说下环境变量设置在哪里,传统说法是~/.bashrc,一起也确实管事,但最近通过kdm,gdm启动的实际上不读这个文件了(不太清楚什么时候变了,当然变了也并非没有道理,本身就是给bash用的何必读呢?),于是管事的最近成为了~/.xprofile,这里需要注意。另外qt可以也通过qtconfig选择im module。

5、更加复杂的情况

libwebkit,office系的程序,等等复杂的gtk程序输入框的处理恐怕也非如此原生于gtk的widget,于是也会出现这样那样的问题。

综上所述的话windows这种为什么这么舒服……就是因为有一个固定的接口把大家统一起来了。至今没有一个一统天下的输入法协议,使得各个输入法甚至不得不维护着和gtk,qt,xim分别相关的三份代码。虽然说xim支持所有的程序,但是不待见xim的程序也很多。

如果给各个软件支持输入法程度排个操蛋的序的话就是这样:

1、只支持XIM,但支持不好 < 2、支持im module,但都支持不好 < 3、支持im module,xim支持不好 = 4、支持im module,但只有xim支持得好 < 5、都支持得不错

第一类典型就是修复bug前的Opera 11

第二类暂时想不出

第三,四类有firefox,ooo,libwebkit

第五类包括所有kde和qt程序。这也基本是我讨厌gtk程序的原因。

其实还有第六类,对用户来说最可恶,就是喜欢在一到五类之间来回在升级版本之后来回蹦跶的,比如gnome-do和flash,最近chromium似乎也榜上有名。

在如此fxxk的情况下,还坚持用着Linux的各位,还在开发着Linux的输入法的各位,给Linux输入法不断提出建议的各位,我向各位表示敬意。本文同时也解释了一些不属于输入法的bug,于是如果你们遇见了类似的问题,请去端掉对应程序的buglist/issue list/bugzilla,如果不确定的话,在得到输入法开发人员的确认之后,也欢迎继续端掉他们的buglist,在输入法用户属于Linux用户小群体的情况下,不主动汇报问题,是不能解决问题的;同时也提出了一些不是Bug的问题,希望在遇见这些问题之后,请压制住自己的火气,慢慢按照步骤解决它。

Posted in Linux, 日志 | Tagged | 8 Comments

我对发行版的印象

仅代表个人观点。

Archlinux:最爱。

Fedora:蓝帽子,包管理虽然速度有提升但是总是不让人放心。

Ubuntu:推荐给刚接触Linux的人用。

KUbuntu:最烂的KDE发行版,没有之一。

XUbuntu,Edubuntu,Lubuntu:马甲。

OpenSUSE:KDE友好的发行版,由于有obs源不是一般的混乱,经常搞不清楚每个源作用。包管理很慢,国内源似乎也略少。

Chakra:半路出家的家伙,pure KDE,以前的livecd bug不是一般的多。

Mandriva:大公司搞基的牺牲品,在KDE4还用类KDE3界面。

MagicLinux:nihui参与的发行版……升级会挂掉。

Debian:更新速度蜗牛一般的发行版,另外非常古板的家伙。

CentOS:给服务器用的。

Gentoo:不环保。

Slackware:和Arch冲在第一线的基友,包管理不如Arch友好。

LFS:和Gentoo一样不环保。

Mint:Ubuntu非官方马甲。

Posted in 日志 | 25 Comments

新桌面

Blue Sora

颜色自配。

=-=-=-=-=
Powered by Blogilo

Posted in KDE | Tagged | 9 Comments

Amarok vs mysql 5.5.8 之二

事实上是杯具的mysql 5.5.8,相关bug是这个:https://bugs.kde.org/show_bug.cgi?id=252424

根据其中的回复,fedora已经放出了patch,事实上这个patch也异常简单。

我已经重新make了mysql 5.5.8,现在看来工作正常。

mysql相关的bug是这个:http://bugs.mysql.com/bug.php?id=59280

PKGBUILD的下载地址在这里:http://csslayer-aur-repo.googlecode.com/files/mysql-5.5.8-6.src.tar.gz

=-=-=-=-=
Powered by Blogilo

Posted in 日志 | Leave a comment

小叙一下下一步的计划

说起来,有一个月没给fcitx写代码了。不过最近的问题也不算太多吧大概。
近况就是搞了两本书作为下一步的参考。缓慢的推进cmake的迁移和4.1的开发中,方向和路线没有太大变化,详情还是参考以前的blog。
另外一个就是port googlepinyin过来,当然是指手机上面的那个,以前已经有个scim的了,这次有了sunpinyin的经验,大概会简单点吧。
另外上次被libpinyin的叫去讨论pinyin切分,不过基本是打酱油。不够既然连aur上都没有相关的包,大概还没完全稳定吧,所以port的工作放到以后再说好了。
说起来,这次可能又会像去年八月那样憋个比较长的时间吧。
闲话不多说了,就到这里吧。

Posted in fcitx development | Tagged | 7 Comments