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

[offline]

　 fcitx5 改用 C++ 编写，这不是什么大问题。只是依赖项大大增加，比如依赖 fmt, xcb-imdkit 以及更加庞大的 boost. 另外它似乎不再提供基于 GTK 的配置工具，只有基于 QT 的配置工具。并且该配置工具不仅依赖 QT, 同时还依赖 KDE. 感觉由于 fcitx 的作者自身是 KDE 用户，所以倾向于将它制作成跟 KDE 桌面紧密关联。不知有多少人也像我一样继续使用 fcitx4, 不愿升级到 fcitx5 ?


　 fcitx5 的拼音输入效率明显高于前版，比如有了“预测”功能。就是当输入一个比较长的专有名词时，比如“巴布亚及新几内亚”，无须输入全部，只需输入到“巴布亚”甚至“巴布”，就跳出候选项“巴布亚及新几内亚”。这种功能在其他平台早就有了，比如安卓手机上的谷歌拼音输入法在十几年前就有。由于 fcitx5 直到 2020 年才去掉 beta 标签正式发布，那么在之前的漫长时间里，难道就没有人为 fcitx4 制作补丁，为其增加该功能？个人感觉这项功能应该不太难实现，按理来说如此实用的功能早就存在了。如果有这类补丁，烦请告知，让我更好地继续使用 fcitx4.


　　另外 fcitx4 的缺省词库非常小，但它提供了一个转换搜狗词库的工具，可以用上搜狗细胞词库。除此之外，它还能用上其他词库吗？比如有一个：

https://github.com/felixonmars/fcitx5-pinyin-zhwiki

是为 fcitx5 制作的大词库，有无工具可以将其转换成 fcitx4 的词库？另外还有一个：

https://github.com/studyzy/imewlconverter

是词库转换工具，似乎并不怎么好用，大家过去在使用 fcitx4 的漫长岁月里有无其他什么好的词库？


　　除了内置的拼音输入法, fcitx4 还支持其他外接的拼音输入法。比如 googlepinyin, sunpinyin 和 libpinyin. 前两个我没用过，因为据了解 libpinyin 是集大成者, libpinyin 应该是最好的拼音输入引擎. fcitx 的内置拼音简单生硬地将同一个拼音的词语按照词库里的先后顺序罗列出来，因为它的词库里根本没有词语频度的相关信息。当然在使用一段时间后，会按照用户的输入习惯调整词频。但初次输入一个词语普遍非常痛苦，往往要翻上好几页才能出现侯选词。而 libpinyin 的输入算法强多了，因为它的词库自带了词语频度信息，在初次输入时就能将常用词汇排到前面。

　　但 libpinyin 自带的词库太小，有无什么工具可以将其他词库转换过来？上面提到的 imewlconverter 转换出来的词库似乎不符合 libpinyin 的要求。大家以前在使用 fcitx4 下的的 libpinyin 输入法时，有无什么好词库？

[astolia]

fcitx5什么时候依赖kde了？明明就是发行版负责打包的人犯脑残干出来的破事，debian的人一年前犯了错也在半个月内改正了 https://bugs.debian.org/cgi-bin/bugrepo ... ug=1014928

剩下的你去看fcitx作者的自己回应吧 https://www.csslayer.info/wordpress/fci ... %E5%BA%94/

[onlylove]

看了下csslayer的回复，和下面的评论，以及suse那边的帖子，
人和人想要相互理解真的挺难的，特别是在认知有差距的情况

对大多数普通用户来说，软件这东西，有啥用啥，不好用就换个，换了一圈还不好用……就用那个相对好点的

我用了很长时间fcitx，最近换成ibus了，理由挺扯的，因为fcitx的中文状态不能输入这一对【】括号
我去搜过解决方法，要编辑fcitx的一个文件（sudo vim /usr/share/fcitx5/punctuation/punc.mb.zh_CN），把里面的改两行，
不过讲道理我不太明白为什么，不知道是因为字体问题？locale问题？还是debian打包问题，或者其他的原因导致的

总之ibus能输入，就用它好了，虽然这一对括号我平时也不会用，
我觉得这个应该等debian或者fcitx去弄，或者至少有人告诉我为啥

不管是开源的，还是商业的，把有问题的软件给用户，然后说，“代码给你，解决方法给你，你自己搞”并不友好，只会显得你很忙
对。我没付钱，你也没为我修的义务，我用别的就是，毕竟就算我付钱了，你也不一定有时间不是

[offline]

fcitx5什么时候依赖kde了？明明就是发行版负责打包的人犯脑残干出来的破事，debian的人一年前犯了错也在半个月内改正了 https://bugs.debian.org/cgi-bin/bugrepo ... ug=1014928

剩下的你去看fcitx作者的自己回应吧 https://www.csslayer.info/wordpress/fci ... %E5%BA%94/

Fcitx5 的配置工具确实依赖 KDE 的相关库，而非像 Fcitx4 那样只依赖 QT. 另外 Fcitx4 不仅提供基于 QT 的配置工具，同时还提供基于 GTK 的配置工具。那才是真正的“桌面中立”，现在明显是增加了跟 KDE 的关联. IBus 跟 GNOME 关联，而 Fcitx5 跟 KDE 关联，都不是桌面中立的输入法。

Fcitx 作者根本没回应我的帖子，他只是为了发泄自身情绪。甚至歪曲事实，将 GLib, Cairo, Pango 这些通用库也算到 GTK 里去。哪怕他这种统计方法非常荒谬, GTK 也依然比 QT 小得多。

[offline]

看了下csslayer的回复，和下面的评论，以及suse那边的帖子，
人和人想要相互理解真的挺难的，特别是在认知有差距的情况

对大多数普通用户来说，软件这东西，有啥用啥，不好用就换个，换了一圈还不好用……就用那个相对好点的

我用了很长时间fcitx，最近换成ibus了，理由挺扯的，因为fcitx的中文状态不能输入这一对【】括号
我去搜过解决方法，要编辑fcitx的一个文件（sudo vim /usr/share/fcitx5/punctuation/punc.mb.zh_CN），把里面的改两行，
不过讲道理我不太明白为什么，不知道是因为字体问题？locale问题？还是debian打包问题，或者其他的原因导致的

总之ibus能输入，就用它好了，虽然这一对括号我平时也不会用，
我觉得这个应该等debian或者fcitx去弄，或者至少有人告诉我为啥

不管是开源的，还是商业的，把有问题的软件给用户，然后说，“代码给你，解决方法给你，你自己搞”并不友好，只会显得你很忙
对。我没付钱，你也没为我修的义务，我用别的就是，毕竟就算我付钱了，你也不一定有时间不是

并非不能相互理解，而是有些人道德品行差，自以为写了一个输入法软件就可以高高在上地侮辱他人。

你认真看一下我在 Suse 论坛的帖子以及作者之后写的博客回应就知道，他完全是在歪曲事实，强行洗地。明明现在的 Fcitx5 越来越复杂，依赖越来越多，跟 KDE 的关联趋势越来越明显，却不承认。对于 GTK 比 QT 小巧得多这一事实也要强行歪曲，甚至还对我人身攻击。要知道，我只是在 Suse 论坛发了一个帖子提问，了解一下怎么更好地继续使用 Fcitx4. 没有攻击任何人，也没有将自身喜好强加到他人身上，但 Fcitx5 的作者却倒打一耙地说我攻击了他。

[onlylove]

关于依赖的事情……打包人和开发的认知和态度并不完全一致吧，
对于开发者来说，代码在为了将来维护和扩展的情况下，短期的增加是可以接受的，毕竟系统基础组件在增加，依赖底层的上层不得不跟着增加，
就不知道打包人怎么想了，不一样的打包人的打包策略确实可能会引起一系列的连锁问题，特别是在某一功能有多个可选依赖的情况下，如果某个打包的对某个选项有偏好，然后偏偏那个体积大点，或者依赖多点，那就会装很多非必须的东西，debian的包不也有recommend suggest之类的区别，如果是因为打包人的策略导致的问题，脾气大的开发当然不愿意背锅，开发也只是人，不是圣人，骂两句人那也没法
至于fcitx4，作者可能只是觉得过时老旧代码不好维护，也不好添加新功能了吧
至于gtk和qt，只要硬盘不是太紧张，别太介意了，反正这两家各自有各自的问题，里面具体的是是非非恩恩怨怨普通用户也不会懂，很多软件的ui在转向qt这是事实

[astolia]

也没有将自身喜好强加到他人身上

你的“初心”一句已经是将自己对“短小精悍”的喜好强加到fcitx开发者身上，甚至还包含了道德审判的意味。

反正几个帖子看下来，你给我的印象是缺乏软件开发的经验，对Qt/GTK的生态一知半解，就在那里大放厥词指指点点。

[astolia]

关于依赖的事情……打包人和开发的认知和态度并不完全一致吧，

这其实不是打包的问题，我开始的回复可能误导你了。楼主对依赖的纠结，在我看来归根结底就是楼主的认知有问题。

fcitx5-config-qt确实依赖几个libkf*的库，但那几个库纯粹是对qt库功能的扩展，仅仅是由KDE那边进行维护而已

这在软件开发界是再常见不过的一件事：我开发的软件X实现了某个功能，我觉得这个功能很好其他人也会需要，就把功能做成一个单独的库。这样我和其他人都可以使用这个库来实现这个功能。这种情况下没有任何人会说你用了那个库的软件就依赖我的软件X。

而楼主非要把这种依赖几个独立库的情况说成是依赖kde，然后引伸出一堆奇谈怪论。

[offline]

关于依赖的事情……打包人和开发的认知和态度并不完全一致吧，
对于开发者来说，代码在为了将来维护和扩展的情况下，短期的增加是可以接受的，毕竟系统基础组件在增加，依赖底层的上层不得不跟着增加，
就不知道打包人怎么想了，不一样的打包人的打包策略确实可能会引起一系列的连锁问题，特别是在某一功能有多个可选依赖的情况下，如果某个打包的对某个选项有偏好，然后偏偏那个体积大点，或者依赖多点，那就会装很多非必须的东西，debian的包不也有recommend suggest之类的区别，如果是因为打包人的策略导致的问题，脾气大的开发当然不愿意背锅，开发也只是人，不是圣人，骂两句人那也没法
至于fcitx4，作者可能只是觉得过时老旧代码不好维护，也不好添加新功能了吧
至于gtk和qt，只要硬盘不是太紧张，别太介意了，反正这两家各自有各自的问题，里面具体的是是非非恩恩怨怨普通用户也不会懂，很多软件的ui在转向qt这是事实

并非打包者的问题，打包者只是误将 libkf5plasma5 列入依赖而已。哪怕去除 libkf5plasma5, 它依然依赖其他的 KDE 库。

[offline]

也没有将自身喜好强加到他人身上

你的“初心”一句已经是将自己对“短小精悍”的喜好强加到fcitx开发者身上，甚至还包含了道德审判的意味。

反正几个帖子看下来，你给我的印象是缺乏软件开发的经验，对Qt/GTK的生态一知半解，就在那里大放厥词指指点点。

我说的是 Fcitx 自身远离了初心，而非作者忘记了初心。他有无忘记，我无从得知。并且现在的作者并非最初的作者，换了人就变了开发方向也没什么奇怪的。它最初确实是小巧输入法，并且宣称“桌面中立”。但现在显然不再小巧，也不是“桌面中立”。并且这句话没有人身攻击，作者要将 Fcitx 往什么方向发展，那是他自己的权利，我没有任何语气要他听我的。

大放厥词指指点点的他们好不好，他们强行将 GLib, Cario 和 Pango 这些非 GTK 程序也使用的通用库（甚至 QT 自身都依赖 GLib）算到 GTK 里去，我指出他们的错误。他们没有一个正面回应。甚至哪怕算进去, QT 依然比 GTK 大得多。并且我也并没反对依赖 QT 呀，我不喜欢的依赖 KDE 和 Boost 等一大堆的东西。他们指出我的错误，比如 QT 并不依赖 Cario 等等，我坦率承认。但他们认为“GTK 跟 QT 的体量没差别”的，有哪个认错的？他们只会转移话题继续围攻我。


我没有要求任何人跟我一样，非常清楚地知道自己是小众需求。总不能因为我的需求小众（并且没要求其他人必须满足我），就要被大众需求攻击吧？就好比市场上流行智能手机，有些人却喜欢传统的功能手机。于是来提问：“现在的手机越来越复杂，越来越砖头化，怎么才能更好地继续使用非智能手机？” 然后被众多智能手机用户围攻，说什么：“功能手机并不比智能手机小巧多少，并且你根本不懂得手机生产制造的原理。什么都不懂，就不要跑出来献丑了。说得越多就越错……”

“功能手机并不比智能手机小巧多少”不符合事实，该传统手机爱好者也可能真的对手机生产制造行业一无所知，但它提出这种需求，就该被围攻吗？


真相在于 Fcitx 作者在回帖中的一句话：历史恩怨。之前有其他人向它提出过类似需求，并且可能导致了严重的争执。导致他耿耿于怀，然后看到我的求助帖子，就想找我这个无辜者来发泄他的情绪。

当然我不指望说服你呀，因为我知道你自身并非像我那样追求软件小巧。能不跟着他来攻击我，我已经很满足了。我写下这些只是为了说明：简单地提出一个自身的小众喜好想法，居然惹来“教主”和“教徒”们的围殴。

[yq-ysy]

我没有要求任何人跟我一样，非常清楚地知道自己是小众需求。

我的需求更小众，我是希望有一款能在Linux系统中使用的笔画输入法，而且是依靠数字小键盘输入的。
Windows下有一款类似的商业软件，Linux没有。于是我自己花了近5年的时间，编出了码表。
但我不会写程序，然后在Github里给十几个输入法开发者留言，希望能他们在开发输入法时用我的码表，结果大都没有回音。
唯一有回复的一个是德国的网友，他曾经修改过ibus-table的代码，他最初稍微有点兴趣，后来太忙也没下文。

最后好在看到Rime支持用自定义的码表制作自己的输入法，又问开发者是否支持数字小键盘输入，得到否定的回答。
问Rime开发者能否开发支持数字小键盘输入的功能，回答没时间。
后来就只能自己硬啃Rime，花了大概一两个月吧，终研究配置出来了能用数字小键盘输入的Rime版“单手笔顺输入法”。
为了解决自己打字的小众需求，每天除了工作吃饭睡觉，业余时间放弃娱乐健身社交，坐在电脑前花整整5年时间，只为一件事……
——不是偏执狂做不了这事的。

我用的是UbuntuStudio系统，之前默认带的是ibus，所以之前我用ibus-Rime就能用我的“单手笔顺输入法”。
现在新版UbuntuStudio系统，默认改为自带的是fcitx，在软件商店找到fcitx5-Rime，当然就必须安装fcitx5，依然能继续用我的“单手笔顺输入法”。

在两三年前，我就已经在github的fcitx5里建议开发支持自定义码表、支持数字小键盘输入……
在两周前，我又重新给github的fcitx5发了一帖，首先赞扬了一下fcitx5，说我已经能用fcitx5-Rime实现自己的输入法了，
然后又一次询问是否支持自定义码表、支持数字小键盘输入？这样我就能不依赖Rime，直接用fcitx5实现自己的输入法了……依然没有回音。
——我的需求太小众了，不值得他们花几分钟打字回复。

我用了很长时间fcitx，最近换成ibus了，理由挺扯的，因为fcitx的中文状态不能输入这一对【】括号

这个问题我也遇到了，所以我在自己的码表里编写有了：0035 就能打出【】，0005 是《》，0002是“”。
有空也体验一下“单手笔顺输入法”吧，不用双手打字，身体歪歪扭扭摊坐着也行，键盘歪歪扭扭远远放着也行，轻松舒适。双手打拼音的人是体会不到的。
到现在我用了二年多，除了没有云词库，感觉没什么问题，越用越顺。

[astolia]

大放厥词指指点点的他们好不好，他们强行将 GLib, Cario 和 Pango 这些非 GTK 程序也使用的通用库（甚至 QT 自身都依赖 GLib）算到 GTK 里去，我指出他们的错误。他们没有一个正面回应。甚至哪怕算进去, QT 依然比 GTK 大得多。并且我也并没反对依赖 QT 呀，我不喜欢的依赖 KDE 和 Boost 等一大堆的东西。他们指出我的错误，比如 QT 并不依赖 Cario 等等，我坦率承认。但他们认为“GTK 跟 QT 的体量没差别”的，有哪个认错的？他们只会转移话题继续围攻我。

我就直说吧，你的这些观点，在用gtk/qt搞过软件开发的人看来，是非常荒诞可笑的。具体笑点在哪里，也只有真正用gtk/qt写过程序的人才知道，你自以为指出了别人的错误，实际上别人是在看你的笑话。

就拿你念念不忘的库文件大小来举例，gtk按它自己的说法，是“A free and open-source cross-platform widget toolkit”，而qt呢，“The most complete set of libraries for UI development, business logic and machine-to-machine communication.”。widget toolkit不过是包含在UI development里的一部分而已。对应到库文件，libgtk*.so提供的各种widget，也只是libQtGui*.so中的一部分而已。所以搞过开发的人，要对比自然是对比实现同样功能需要的库，看到你就直接拿gtk对比qt，感觉就像是拿计算器和计算机对比一样。

其实上面onlylove说的挺好的，这就是个认知的差距。你对一些概念的理解，和一般程序员的理解上是有很大差异的。你拿着你的理解去和程序员对线，在程序员来看就是各种双标，被当成故意找碴的民科也不奇怪

[offline]

大放厥词指指点点的他们好不好，他们强行将 GLib, Cario 和 Pango 这些非 GTK 程序也使用的通用库（甚至 QT 自身都依赖 GLib）算到 GTK 里去，我指出他们的错误。他们没有一个正面回应。甚至哪怕算进去, QT 依然比 GTK 大得多。并且我也并没反对依赖 QT 呀，我不喜欢的依赖 KDE 和 Boost 等一大堆的东西。他们指出我的错误，比如 QT 并不依赖 Cario 等等，我坦率承认。但他们认为“GTK 跟 QT 的体量没差别”的，有哪个认错的？他们只会转移话题继续围攻我。

我就直说吧，你的这些观点，在用gtk/qt搞过软件开发的人看来，是非常荒诞可笑的。具体笑点在哪里，也只有真正用gtk/qt写过程序的人才知道，你自以为指出了别人的错误，实际上别人是在看你的笑话。

就拿你念念不忘的库文件大小来举例，gtk按它自己的说法，是“A free and open-source cross-platform widget toolkit”，而qt呢，“The most complete set of libraries for UI development, business logic and machine-to-machine communication.”。widget toolkit不过是包含在UI development里的一部分而已。对应到库文件，libgtk*.so提供的各种widget，也只是libQtGui*.so中的一部分而已。所以搞过开发的人，要对比自然是对比实现同样功能需要的库，看到你就直接拿gtk对比qt，感觉就像是拿计算器和计算机对比一样。

其实上面onlylove说的挺好的，这就是个认知的差距。你对一些概念的理解，和一般程序员的理解上是有很大差异的。你拿着你的理解去和程序员对线，在程序员来看就是各种双标，被当成故意找碴的民科也不奇怪

直接说就是了，何必来一句“我就直说吧”，好像装作担心得罪我似的。要是真的担心得罪我，恐怕那个帖子里不会有那么多人在嘲讽我的小众爱好。

你能正面回答我吗？


1. 至于 GTK 和 QT 哪个好，是自身喜好，就像 Vim 和 Emacs 哪个好一样，各有各的看法. 至于“ QT 虽然更大，但它带来了更多好用的功能”，那也只是价值判断，属于自身喜好，真没必要用来转移它更庞大的事实. GTK 的块头明显比 QT 小，这是事实，为何总有人对铁的事实进行歪曲？歪曲的目地在哪里？要做一个普通的 GUI 程序，比如非常简单的文件编辑器。分别用 GTK 来做和用 QT 来做，结果就是后者比前者所依赖的库大了许多。至于哪个更容易开发，对开发者更加轻松，那是另外一回事。你将 GTK 和 QT 分别比作计算器和计算机，且不说两者是否真的差距那么多。就算是，我的功能用计算器能完成，为何要去用更加庞大复杂的计算机？

2. 将 GLib 这种库强行算作 GTK 的一部份，合理吗？因为 GLib 和 GTK, GNOME 的开发人员有很大的交集，就将它们捆在一起？如果真要捆在一起，也不会独立成一个项目了。

3. 从哪里看出我讨厌 QT, 而喜欢 GTK 了？我从没说过，而是一堆 QT/KDE 的粉丝强加给我的。在他们看来，只要不是 QT 的粉丝，就一定是 GTK 的粉丝。只要没赞美 QT/KDE 的，就是我的敌人。就算我真的喜欢 GTK, 喜欢 QT. 也真不妨碍别人吧。我只是说了 fictx5 依赖 KDE 的东西，变得很复杂，不再桌面中立了。

4. 用基于 C 语言的 GTK 开发比用基于 C++ 语言的 QT 更痛苦，那是开发者自身的事情。我当然知道，但跟我的需求没有任何关系，我又没要求开发者采纳我的需求. Fcitx5 的教主以及教徒用此来攻击我，说我根本不知道开发人员有多艰辛，逻辑在哪里？

5. 假如你开发一个 Web 服务器软件，依赖了 libX11. 被他人拒绝使用，认为服务器上的东西不应该依赖 GUI 的库。然后你说：“依赖 libX11 不等于依赖 XOrg Server. 并不需要在服务器上开启 X Server, 只是多了几兆大小的库而已。因为服务器上缺乏一些好的库，而刚好 libX11 里头有些函数可以大大加速我的开发。你这个服务器上的运维人员根本不懂得怎么开发软件，一个民科在大放厥词……” 逻辑在哪里？当然这个例子在现实之中不会存在，因为服务端软件禁止依赖 libX11 是一种大众心理，你没那个胆量为了自己便于开发而去得罪大众心理。而对于输入法不应依赖 KDE 的相关库，那就只是我的小众爱好，所以被人攻击了。说到底还是党同伐异、人多势众就欺压弱小一方的心态在作怪。


我当然不指望你们会认错，写那么多只是希望其他有小众需求的人有勇气说出自己的想法，不要因为被群殴就妥协。一伙人对我群起而攻之的唯一原因就是我的小众需求让他们感到不爽，他们渴望享受那种压制别人的快感。

[百草谷居士]

我以前也对于安装一个软件包依赖一大堆东西极为反感。现在它只要不影响桌面环境，添加桌面应用，随他去吧。那些个运行库，反正这个不依赖，那个依赖。早不添加，晚添加，早晚要添加，随他去吧！Linux系统用的时间长了，总是要添加一大堆东西的。想开就好！astolia 版主常常指责我是不求甚解，得过且过，说我是个伸手党。我一个老会计，使用 Linux 来办公，已经够不容易了。如果还想事事搞明白，恐怕会严重影响工作，丢掉饭碗的

[offline]

纠正一下上面的错误：

就算我真的喜欢 GTK, 喜欢 QT. 也真不妨碍别人吧。我只是说了 fictx5 依赖 KDE 的东西，变得很复杂，不再桌面中立了。

应该改成：

就算我真的喜欢 GTK, 不喜欢 QT. 也真不妨碍别人吧。我只是说了 fictx5 依赖 KDE 的东西，变得很复杂，不再桌面中立了。

少了一个“不”字。