Why fcitx need refactor?

首先诸君没必要给Fcitx加上各种定义，定义是人定的。最重要的就是开发者定的。然后不幸，现在这个人是我。

轻量？简洁？快速？这大概是多数人对于fcitx的看法。

我心中的理想的fcitx是什么样的？

可用性（Usability），原生（Native），KISS。

第一条，在这方面做的努力可能注意不到，在3.6时代困扰不少人的方块字问题，后来通过Fontconfig和Pango（如果禁用Pango就是Fontconfig找字体了）得到了相对比较好的解决。

第二条，这单纯是个人喜好，似乎也是很多linux用户的喜好。界面要原生。Fcitx的界面原生吗？没有使用GTK/Qt，谈不上原生，但是这个皮肤引擎给了Fcitx原生的能力，比如我就曾经写过一个小程序，使用KDE的Plasma主题生成Fcitx的皮肤。

即使对于GNOME来说，我其实也没有必要去写什么利用GNOME-Shell做的界面，不过他那个bug如果不给我解决掉（不是那个xim的，是关于界面显示的，其实是影响所有程序的一个bug），那还是只能悲剧。

第三条，Fcitx的架构其实一直非常简单，一直也没有引入什么更多的外部依赖（除非有必要），现在Fcitx需要发展的话，其实将不得不使用更多依赖，不过不用担心，这些不仅可以在编译时确定，同时也可以在安装时，运行时确定。

为什么我一直执着于不引入高级库的抽象？除了为了满足一些人的洁癖之外，更重要的原因就是保持简单。对于内部的事件处理，虽然当然也可以用比如libevent，或者gio，或者别的什么，但是它相对也不会带来什么用户可见的好处。（最影响Fcitx速度的部分是输入法引擎，用sysprof测定过），增加我的各种学习成本……

另外也就是留下各种余地，如果有一天Fcitx要做更大的跨平台动作，那些某个平台上没有的库希望也不会成为阻碍。

$ ldd /usr/bin/fcitx
linux-vdso.so.1 =>  (0x00007fff4e5ff000)
libfcitx-core.so.0.1 => /usr/lib/libfcitx-core.so.0.1 (0x00007f8677546000)
libfcitx-config.so.4.1 => /usr/lib/libfcitx-config.so.4.1 (0x00007f867733b000)
libfcitx-utils.so.0.1 => /usr/lib/libfcitx-utils.so.0.1 (0x00007f86770fa000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f8676edd000)
libc.so.6 => /lib/libc.so.6 (0x00007f8676b7c000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f8676978000)
/lib/ld-linux-x86-64.so.2 (0x00007f8677754000)

其实Fcitx变得更轻了而不是更重了。

顺便说点别的（虽然我想说点Neta…比如和Fcitx签订契约成为魔法少女吧！）

欢迎有兴趣参与Fcitx开发的人和fcitx-dev@googlegroups.com联系（我很讨厌可以将联系更加公开的时候联系我个人，所以不要给我发信）。至少现在还是有很多事情可以做的，不过你指望有人付钱那是没戏的……

比如说：

fcitx-anthy（有个挖了个坑连水都没填的家伙说要做这个，所以不必介意他）

fcitx-libpinyin（一个新pinyin库，似乎有各种做拼音的人参与）

kimpanel的GNOME-Shell版本（这个其实和fcitx没直接联系，不过有了这个fcitx在GNOME-Shell下的显示问题就可以解决了）

fcitx-{…}，你还能想到的其他功能。比如m17n…或者MAC OS移植等等。