对“fcitx5 依赖 boost 和 KDE, 探讨继续使用 fcitx4 的可行性“的回应

原贴：https://forum.suse.org.cn/t/topic/15817/7

首先，要对其中的几个所谓的错误说法进行驳斥。

1、Fcitx 5 依赖 KDE 和 Boost？

这是错误的，作为高度模块化的项目，核心库和服务器，输入法引擎，配置界面都是分离的代码库。

核心部分，反而比以前要精简得多，因为 gtk 和 qt im module 都变成了独立的项目，事实上，如果你乐意，可以编译出一个和图形库无关的 fcitx，这也是 fcitx5 能被移植到 android 上的基础。

输入法引擎部分，现在新的拼音引擎使用了极少的一部分 boost，大部分都是 header only 的，只有几个少量和 io 相关的库需要 boost 的共享库。如果你的发行版拆包精细，将只是引入约 500k 左右的依赖。

而配置界面的部分，则可能是有疑问的了，事实上它本身是在同一个代码库内分解成了两个实现，一个是只依赖于 Qt 和少量 KF5 的库，另一个则是和 KDE 系统设置集成的，也就是和 fcitx4 的 kcm-fcitx 的等价物。对于基于 QtWidgets 的实现，在 Qt 之外只引入了 1.6M 的依赖。和它所依赖的 Qt 库总计 19M 相比可以说是九牛一毛了。

而且时常大家会对 Gtk 和 Qt 在磁盘容量上有一些错觉，认为 Gtk 是 C 所以就「light」，编译出来的代码量就要小得多。而事实上如果你将相关的图形，字体，io，dbus 相关的库统统加起来，才能等价于那几个 Qt 的库。仅做一个不严谨的比较的话，Gtk 需要的依赖在我的系统上

992K    /usr/lib/libgdk-3.so.0.2405.32
7.8M    /usr/lib/libgtk-3.so.0.2405.32
1.3M    /usr/lib/libglib-2.0.so.0.7600.1
1.2M    /usr/lib/libcairo.so.2.11708.0
416K    /usr/lib/libpango-1.0.so.0.5000.14
64K     /usr/lib/libpangocairo-1.0.so.0.5000.14
96K     /usr/lib/libpangoft2-1.0.so.0.5000.14
1.9M    /usr/lib/libgio-2.0.so.0.7600.1
14M     总计

228K    /usr/lib/libKF5ItemViews.so.5.104.0
1.4M    /usr/lib/libKF5WidgetsAddons.so.5.104.0
5.2M    /usr/lib/libQt5Core.so.5.15.8
508K    /usr/lib/libQt5DBus.so.5.15.8
6.4M    /usr/lib/libQt5Gui.so.5.15.8
6.8M    /usr/lib/libQt5Widgets.so.5.15.8
24K     /usr/lib/libQt5X11Extras.so.5.15.8
21M     总计

在 Fcitx 5 中移除了 fcitx-config-gtk 之后减少了我本人大量的维护工作，因为 fcitx5-config-qt 和 kcm-fcitx5 有许多代码是可以共享的。如果有些基础常识的话，也知道用纯 C 写代码会有多么痛苦。如果你想说 Gtk 有 js binding / python binding，那是否又徒增其他语言的依赖了呢？

现在，只要你乐意，写一个基于 ncurses 的 fcitx 配置界面也没什么不可以，或者你想复活 fcitx-config-gtk 我也没有意见，但是请不要指望我去写，因为没有那个时间精力。

2、Fcitx 5 的拼音支持变少了？

表面上来说，是这样的，曾经有自带拼音，libgooglepinyin，sunpinyin，libpinyin，看起来仿佛百花齐放非常热闹，但实际上如果你对他们有所了解的话：

自带的拼音的基于最大前向匹配的算法不会比20年前的智能 ABC 好到哪去，最多就是沾了一个云拼音和词库更大的光。

libgooglepinyin 是移植自一个古老 android 版本的拼音库而且有已知的问题在特定输入会崩溃，算法本身是 unigram，也是没有上下文预测能力的。

libpinyin 是 bigram 的模型，但在几年间我对它的使用经验就是：多次随意 break ABI，早期的低质量数据输入提示有大量错字作为默认选择。

sunpinyin 是 fcitx5 当中采用的 libime 的设计精神来源，也就是trigram 的拼音输入法。如果你稍微了解一些关于 ngram 的知识，当 order 越高的时候，对上下文整句的预测也会更加准确。但在更早一篇博客我已经写过和 sunpinyin 的对比。Sunpinyin 的输入历史会被快速遗忘，没有多词库功能。而 libime 采用和 sunpinyin 相同的算法原理但是采用了存储方面更加优秀的 kenlm 作为语言模型的二进制格式，在同样的效果上占用的内存相比 sunpinyin 更小。在早期的 libime 版本中，语言模型和词库就是采用和 sunpinyin 相同的 open-gram，同样的数据同样的算法事实上计算出的结果也会是完全一样的。所以当初这样考虑之后，根本没必要再去实现 sunpinyin 的支持了。因为在库本身的易用性上，libime 是可以方便支持外挂任意数量的词库文件，拼音解析及继承自 fcitx 4 的拼音但是有额外的改进，也支持了内模糊切分（xi’an 和 xian）等等其他一系列原本 fcitx 4 没有的新功能。

事实上在一个新的 code base 的基础上我们可以自由引入许多新的功能，例如语言模型和词库也已经不是最早的 open-gram 而是用更新的数据重新训练的。词库也增加了许多新的词汇，双拼也支持了完全自定义音节。sunpinyin 在近几年已经完全没有更新过，即使不考虑功能上的更新，数据也完全没有更新过。而由 fcitx 项目掌控的 libime 可以更自由的更新数据，增加新的功能。直接用拼音输入颜文字，拆字等等功能也都是在这个新拼音下才有的。

另外这些都是开源项目，只要你乐意，代码就在那，你可以随时把 fcitx4 的拼音移植过来，但我不会去捡起那个过时的代码库的。

3、fcitx 的初心是什么？

我不能替 yuking 代言，事实上代码库在我主要接手之后的十几年早就经过了长久的演化。早在十几年前因为 GNOME 的某些行为，我是真切对这些东西（opensource，是否要继续fcitx）感到失望而迷茫，当时也写过很多篇博客讨论这些事情。

事实上在我看来 fcitx 的优势就在于它的模块化架构。有很多功能如果你拿到别的框架去实现，你会发现是没法简单扩展的。例如快速输入/unicode在独立于输入法之外而存在的功能，不同输入法之间共享的拼写检查功能（键盘 / 拼音的英文输入是又另一个模块提供的功能），剪贴板的访问等等。

另外从头到尾的对代码库的掌控也提供了更好的对于新功能新平台的支持。ibus 的 qt5 输入法模块至今有许多已知的 bug，也无法在 wayland 下完全正常的使用。fcitx 5 是事实上唯一一个在 wayland 下对 compositor 支持最多最全面最可用的输入法。高度的模块化也让 fcitx 5 现在甚至可以运行在 flatpak 沙盒内。

我并不认为有谁忘记了初心，甚至坚持的很好，不要自己臆想一个初心强加给别人了。