Fcitx 4.2 Plan

Feature Plan:

XKB Integration. (Done)

DBus based input method interface, make it possible to write input method with other programming language and other high level library, like glib or qt. (WIP) (Not one will actually eat this dog food, and inter-process communication is not fcitx style, all the module doing easy in-memory interaction is fcitx’s style).

Context event system, addons can provide context change notification. (Done, basic idea is implemented, need some “real usage”, fcitx-libpinyin already use some, fcitx-xkb will be another use-case).

Demo Mobile support for N9 via Maliit. (Not plan to make it full functional in 4.2, since it’s not so important) (WIP) (Postpone, since not important)

Anthy support. (Done)

Hangul support. (Done)

M17N support. (Done)

If possible, libchewing support. (Done)

Something already implemented, you can grab it from git (Be careful !):

fcitx-chewing, fcitx-libpinyin and fcitx-table-extra is on github.

Provides fallback user interface function, make kimpanel can automatically detect whether kimpanel is started or not, so kimpanel will be the default user interface if kimpanel is available, including Unity and GNOME-Shell. (Video)

Lazy input method loading.

Separate word construct code in fcitx-table, making phrase construction in Zhengma (郑码) works correctly, so we can introduce Zhengma in next release.

Dynamic input method change for fcitx-config-gtk (Already implemented in kcm-fcitx with 4.1.2 release), gtk3 support for fcitx-config-gtk, though no UI improvement.

New Monochrome icon set for kimpanel under KDE.

Some other updates:

It’s possible to translate fcitx on transifex.

Posted in fcitx development | 8 Comments

曾经的白日之梦

我也是学过画画的,在小学的时候。

虽然是微不足道的水彩画和签字笔画的也不知道叫什么的画而已。如果重新看过曾经的画过的画,没有大叫一声“鬼啊”已经算是很好的评价了。

我也妄图写过小说,在中学的时候。

虽然最后高考的语文也没有及格。如果回头去看的话,一定会大叫着“bull shit”然后扔到一边吧。

我早已认识到我没有这方面的天赋。所谓的努力然后成为天才这种故事,是不能适用于这种情况的。

因为我还有更喜欢的东西。那里才是真实的心像世界的投影。

对于这样的情况,没有后悔过。

不过依然曾经做着一个貌似帅气的梦。

制作一个从脚本到美工到程序都是自己完成的One-Man-Game。然后自己玩到感动流泪。

在空无一人的机房里面,偶尔回想起的白日之梦。如果我的人生能重复三次大概能完成的事情吧?

Posted in 日志 | 5 Comments

My Dearest (歌词而已)

罪恶王冠 OP1

so everything that makes me whole
今(いま)君(きみ)に捧(ささ)げよう【现在都奉献给你】
I’m yours

ねぇ こんなに 笑えたことも 生まれて初めてだよ 【呐 像这样开心地笑 出生以来还是第一次】
きっと 私はね  【一定 我呐】
この日のために 间违いだだけの 道を歩いてきたんだ【为了这一天 而走上错误的道路】
ずっと 一人で 【一直 孤独一人】

远く远くの 近までまたで 君と二人 【既靠近又遥远的你我二人】
手を取って 永远に どこまでだって至るはず【只要永远牵着手 无论哪里一定都能到达】
もう一人じゃなって 君は そういいまだあるな【请不要让我再孤独一人 善良的你仍然在我身边】

守るべき大事なものが今あって 【现在拥有应该保护的重要的事物】
だけどなすすべおれんたち尽くす徒费は【然而不知所措的我们再尽力也是徒费功夫】
可能性は 失うで暗暗が意味を【也可能失落在黑暗中的意义】
お威吓し 绝望ある 饮み込むらされたは【就算被恐吓 就算绝望 只要感情被理解】

私が君を照らす光になるから【我如果成为照亮你的光芒】
まだこの世界の槛出って消せわしない【可能就能走出并消灭这个世界的牢笼】

so everything that makes me whole
今(いま)君(きみ)に捧(ささ)げよう【现在都奉献给你】
I’m yours

ねえ この世界(せかい)にはたくさんの幸(しあわ)せがあるんだね【呐 这个世界上有很多种的幸福】
いつか ふたりなら【总有一天 如果是两个人的话】

Whoeverが君(きみ)のこと嘘(うそ)つきと呼(よ)んで【不管是谁称你为骗子】
心无(こころな)い言叶(ことば)で伤(きず)つけようとしても【戓是用无情的语言伤害你】
世界(せかい)が君(きみ)のことを信(しん)じようとせずに【不管世界是否相信你】
茨(いばら)の冠(かんむり)を冠(かぶ)せようとしても 【即使戴上荆棘做的皇冠】

私(わたし)は君(きみ)だけの味方(みかた)になれるよ【我会一直站在你这边】
この孤独(こどく)痛(いた)みを私は知っている【因为我知道这孤独的疼痛】

so everything that makes me whole
今(いま)君(きみ)に捧(ささ)げよう【现在都奉献给你】
I’m yours

顺便追番感想:

展开略慢……不过最新一话终于开始触及世界的真实了,让人想追下去了。能够看见他人内心的黑暗,还是要用主角光环光芒去照亮才好啊。

来源:

http://tieba.baidu.com/p/1315130869

Posted in 歌词 | Leave a comment

难以评论

每当我对某个程序的有意见的时候,我总是禁不住想,嗨,是不是因为我是个Geek所以我才这么想的?

某些东西到底该怎么做?难以评论某些事情到底是撞墙了,还是走对了。

Linux怪圈就是,只有Geek在用 => 变得更加 Geek => 还是只有 Geek 在用。

Posted in Linux | 6 Comments

输入法环境变量的故事

有时候我想想,我是不是应该写一些比较普及的文档(你懂得,我特意纠结了一下措辞)。

那么这次先来介绍一下关于输入法的环境变量配置问题:

在远古时代,世界一片混沌,那时世界上还没有 X 窗口下的输入法支持。

神说,要有输入法,于是就有了 XIM 协议。

这个时代(当然还有个几个XIM协议的版本更新),需要设置的环境变量有

XMODIFIERS=”@im=imname”

比较现代的程序的话,是不用纠结imname这个值的,输入法自己会自己也检测一把这个值,然后启动xim的时候也把自己变成这个值。印象中一定要这个环境变量的程序有xterm。

然后XIM有诸多缺点,至少在输入法程序关闭(不一定是死掉)的时候,可能让程序freeze,或者崩溃。

于是神看到XIM是坏的,授意GTK和QT自己做自己的IM Module。

从此天下大乱。

先来看 Gtk 这边,假设没有环境变量,Gtk是读取一些配置文件里面记录的im module的。每个im module都有指定语言,也就是按环境的语言设置匹配。这里来第一个常见问题:英语环境为什么默认不能用输入法而要纠结 LC_CTYPE=”zh_CN.UTF-8″。就是为了让 Gtk 的匹配能够匹配中文的IM Module。当然我个人是反对这种配置的,因为其实只要 GTK_IM_MODULE 足以。世界上据我所知唯一一个奇葩程序一定要这么设置那就是emacs。(因为作为gtk界面的emacs其实是用XIM协议……鬼知道里面hardcode了啥)

第二个常见问题,为什么卸载了ibus就可以用 fcitx,那是因为系统中同时有两个zh的im module(其实是三个,还包括了xim),你不设置环境变量的话,那就会让gtk自己选择了,这个顺序似乎也不确定,如果选到ibus但你用fcitx,或者选到fcitx你用ibus,都会导致你输入法不能正常使用。

设置了GTK_IM_MODULE之后呢?假设匹配到对应的im module,就会使用对应的im module,假设没匹配到,那就返回之前的没有设置的情况。

LC_CTYPE和设置*_IM_MODULE两种方式我偏好后者。

这里还有个很脑残的问题,GTK一定会去读取 /etc/gtk-2.0/gtk.immodules (按发行版,和cpu架构,以及gtk版本可能不同)里面记录的im module,尽管gtk-query-immodules-2.0和gtk-query-immodules-3.0是可以自己查询的。所以打包者必须自己在安装后脚本内更新这些文件。可能当初Gtk想做缓存……不过现在这年头不缓存也没啥大不了的了。

回到 Qt 这边,情况稍好,首先挑选规则还是如之前所述,按语言。但如果没有环境变量QT_IM_MODUE的干预,这个可以通过 qtconfig 进行选择。以及发行版的打包者们可以不用纠结更新类似GTK那些文件。就这样。

另外顺带一提,QT的环境变量检测是分QT和QT4的,不知道为什么Gtk3发布的时候为什么没有把GTK2和GTK3一起考虑进去。虽然说因此而遭殃的只有一个,那就是scim。如果你不知道它为什么会遭殃的话,请重新学习上文的匹配规则。

(顺带一提其实世界上还有 Clutter 的 IM Module 这种东西。)

话说眺望未来什么的话,那假设进入到了 Wayland 时代,不幸,Wayland 还没有类似 XIM 的统一协议,于是如果程序想支持输入法,最好还是选择 Gtk / Qt 来开发。

Posted in fcitx development | Tagged , , | 11 Comments