fcitx5 改用 C++ 编写，这不是什么大问题。只是依赖项大大增加，比如依赖 fmt, xcb-imdkit 以及更加庞大的 boost. 现在的 fcitx 已经远离了 “初心”，不再是短小精悍的输入法。另外它似乎不再提供基于 GTK 的配置工具，只有基于 QT 的配置工具。并且该配置工具不仅依赖 QT, 同时还依赖 KDE. 感觉由于 fcitx 的作者自身是 KDE 用户，所以倾向于将它制作成跟 KDE 桌面紧密关联。不知有多少人也像我一样继续使用 fcitx4, 不愿升级到 fcitx5 ?
fcitx5 的拼音输入效率明显高于前版，比如有了 “预测” 功能。就是当输入一个比较长的专有名词时，比如 “巴布亚及新几内亚”，无须输入全部，只需输入到 “巴布亚” 甚至 “巴布”，就跳出候选项 “巴布亚及新几内亚”。这种功能在其他平台早就有了，比如安卓手机上的谷歌拼音输入法在十几年前就有。由于 fcitx5 直到 2020 年才去掉 beta 标签正式发布，那么在之前的漫长时间里，难道就没有人为 fcitx4 制作补丁，为其增加该功能？个人感觉这项功能应该不太难实现，按理来说如此实用的功能早就存在了。如果有这类补丁，烦请告知，让我更好地继续使用 fcitx4.
另外 fcitx4 的缺省词库非常小，但它提供了一个转换搜狗词库的工具，可以用上搜狗细胞词库。除此之外，它还能用上其他词库吗？比如有一个：
是为 fcitx5 制作的大词库，有无工具可以将其转换成 fcitx4 的词库？另外还有一个：
是词库转换工具，似乎并不怎么好用，大家过去在使用 fcitx4 的漫长岁月里有无其他什么好的词库？
除了内置的拼音输入法, fcitx4 还支持其他外接的拼音输入法。比如 googlepinyin, sunpinyin 和 libpinyin. 前两个我没用过，因为据了解 libpinyin 是集大成者, libpinyin 应该是最好的拼音输入引擎. fcitx 的内置拼音简单生硬地将同一个拼音的词语按照词库里的先后顺序罗列出来，因为它的词库里根本没有词语频度的相关信息。当然在使用一段时间后，会按照用户的输入习惯调整词频。但初次输入一个词语普遍非常痛苦，往往要翻上好几页才能出现侯选词。而 libpinyin 的输入算法强多了，因为它的词库自带了词语频度信息，在初次输入时就能将常用词汇排到前面。
但 libpinyin 自带的词库太小，有无什么工具可以将其他词库转换过来？上面提到的 imewlconverter 转换出来的词库似乎不符合 libpinyin 的要求。大家以前在使用 fcitx4 下的的 libpinyin 输入法时，有无什么好词库？
1赞
用了这么多年 Linux，第一次听说 fcitx 的初心 
早期的 fcitx 跟同时代的 SCIM 相比，确实属于短小精悍。当然后来 fcitx 也像 SCIM 一样，做成一个平台，而非单纯的输入法。哪怕如此，它依然比较小巧，但到了 fcitx5 时代就不是如此了。
这要看是什么发行版，有些发行版当你安装一个跟 fcitx5 有关的包时，默认就要依赖一大推能使这个软件每项功能都能正常运行的包。而有些发行版你安装一个包就是一个包，不会自动安装其它依赖，你要什么功能你就必须手动安装该功能的依赖。
这个不限定于那个桌面环境，有些发行版默认安装 ibus+KDE 桌面你又该怎么解释呢？（例如 Mageia Linux）
fcitx4 最大的问题是不支持 Wayland。
fcitx5-configtool 不过是依赖上了两个 KDE 那边写的 GUI 组件库而已，怎么就「依赖 KDE」了？那之前的 GTK 版本是不是该说「依赖 GNOME」了？
至于 fmt，不过一个 130K 的小库而已。至于 boost，openSUSE 已经拆包了，fcitx5 也只是依赖其中一个 90K 的 so 而已。
fcitx5 真正令人在意的体验降级，是五笔输入法的排序，不再是按「编码 字词」来排，而是仅按「字词」来排，导致不同编码下同一字的优先级是相同的。
哦对了，用 fcitx5 还有一个好处是，有个项目 将它移植到了 Android 上，因此可以在桌面和手机上使用相同的输入法配置了。
对于暂不使用 Wayland 的我来说, fcitx4 就够用了. fcitx5 依赖的 KDE 组件有好几兆的大小，加上那些 boost, fmt 等依赖，再加上自身代码的膨胀，已经是一个复杂的输入法。
早先 fcitx4 的配置工具既有 GKT 版, 也有 QT 版，没有依赖 GNOME 和 KDE 的任何组件。那才是独立于桌面环境的短小精悍输入法。
gtk 就是 GNOME 的组件啊，跟 k 开头的和 KDE 的关系一样。
GTK 对应的是 QT, GNOME 对应的是 KDE. 不应该将依赖 GTK 说成依赖 GNOME, 现在的 fcitx5 的配置工具却实实在在地依赖 KDE 的组件（并且有好几兆的大小），而不仅仅只是依赖 QT.
u1s1，GTK 和 GNOME 桌面的关系比 Qt 和 KDE 桌面的关系要紧密的多，这样说可能也没毛病。Qt 和 KDE 桌面 的关系应该相当于 GLib/Gio 和 GNOME 桌面的关系。
GKT 虽然跟 GNOME 紧密相关，但由于 GKT 几乎必须安装（有哪个桌面可以少得了？），所以依赖 GTK 并不会导致额外的多余依赖。
比如轻量级的桌面 LXDE 就依赖 GTK, 但它明确要求任何组件都不能依赖 GNOME.
不就两兆么？
gtk 是 GNOME 开发、用的。k* 是 KDE 开发、用的。
现在是依赖 k* 的独立软件不多。但 GNOME 继续 折腾下去，说不好的。
哪怕 GNOME 这个桌面死掉了，也不会有大量独立软件依赖 KDE, 依然会有许多软件作者尽量避免依赖大型桌面的组件。
哪怕 GNOME 这个桌面死掉了, GTK 这个项目也会有人继续 fork 下去。并且依赖 GTK 的软件会比 QT 的多。
虽然 GTK 的问题多多，比如 LXDE 就是由于 GTK3 的许多问题而转到 QT, 但 LXQT 也只是转到 QT 而已，并没依赖 KDE. 其实 QT 的问题不会比 GTK 少，一样有许多麻烦要面对。
哦，那我就不清楚了，因为没用过 LXQT. 我只是最初用 LXDE 的时侯了解到它们的原则是：可以依赖 GTK, 但不能依赖 GNOME. 于是我想然地认为 LXQT 也存在只依赖 QT, 而不能依赖 KDE 的类似要求。
如果安装 fcitx5 的时候自动依赖上了 KDE 桌面，那才是真正要修的问题。现在只是依赖 KDE 框架而已。KDE 框架又没多大，Linux 上也有不少软件，不止是 K 家的，也开始依赖 KDE 框架了。
结果就是新出的 GUI toolkit 一个个汉字渲染不正常、字体配置和回落比 Qt 还差、输入法问题一大堆。