用了这么多年 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 真正令人在意的体验降级，是五笔输入法的排序，不再是按「编码 字词」来排，而是仅按「字词」来排，导致不同编码下同一字的优先级是相同的。
对于暂不使用 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 少，一样有许多麻烦要面对。
你怕是把 KDE 框架和 KDE 桌面搞混了哦
LXQT 一样依赖 KDE 框架的
哦，那我就不清楚了，因为没用过 LXQT. 我只是最初用 LXDE 的时侯了解到它们的原则是：可以依赖 GTK, 但不能依赖 GNOME. 于是我想然地认为 LXQT 也存在只依赖 QT, 而不能依赖 KDE 的类似要求。
如果安装 fcitx5 的时候自动依赖上了 KDE 桌面，那才是真正要修的问题。现在只是依赖 KDE 框架而已。KDE 框架又没多大，Linux 上也有不少软件，不止是 K 家的，也开始依赖 KDE 框架了。
嗯，死掉了的话肯定会，活着的话就不好说了……
1赞
结果就是新出的 GUI toolkit 一个个汉字渲染不正常、字体配置和回落比 Qt 还差、输入法问题一大堆。
哪怕 GNOME 桌面环境没有死掉，只要 GTK 过度地跟 GNOME 捆绑，我相信也会有人无法忍受而去 fork GTK 的。别说 GTK, 甚至 GLib 都有可能会去 fork 的。因为 GLib 也是 GNOME 的那班人在弄. GLib/GTK 这套东西已经广泛应用就很难死掉，会有人接手的，而 GNOME 桌面环境死掉就未必有人接手。