首先诸君没必要给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) … Continue reading Why fcitx need refactor?