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

系统字体配置、中文显示和输入法问题
offline
帖子: 42
注册时间: 2012-02-06 11:26

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

#16

帖子 offline » 2023-04-15 7:35

yq-ysy 写了: 2023-04-14 21:35
offline 写了: 2023-04-14 12:36 我没有要求任何人跟我一样,非常清楚地知道自己是小众需求。
我的需求更小众,我是希望有一款能在Linux系统中使用的笔画输入法,而且是依靠数字小键盘输入的。

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




是的,对于自身的小众需求,就应该自己解决,而不要指望软件作者。我对 Fcitx 的小众需求不会去作者的 GitHub 上提 issue, 因为我清楚他们不可能满足我。

也建议你不要浪费时间去向作者提需求,他们没骂你算你运气好了。要知道,我没去联系作者,而只是发了一个帖子,试图寻找跟我有共同小众爱好的人来探讨,就引来一群人试图改造我。
头像
astolia
论坛版主
帖子: 6450
注册时间: 2008-09-18 13:11

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

#17

帖子 astolia » 2023-04-18 15:24

offline 写了: 2023-04-15 7:07 2. 将 GLib 这种库强行算作 GTK 的一部份,合理吗?因为 GLib 和 GTK, GNOME 的开发人员有很大的交集,就将它们捆在一起?如果真要捆在一起,也不会独立成一个项目了。
我上面说过,你不是开发者,你的理解和一般开发者的认知存在很大区别。
如果你觉得glib和gtk应该分开,那么你把fcitx5-config-qt依赖的libkf*.so和kde捆在一起,就是彻彻底底的双标。libkf*.so所属的kde frameworks https://develop.kde.org/products/frameworks/ 也是一个独立的项目啊?
“将 GLib 这种库强行算作 GTK 的一部份”,这个也是你自己的误读。csslayer在他的博文里说的是“相关的图形,字体,io,dbus 相关的库”,这很明显是基于功能来比较的。我的软件要实现功能abcd,用libQt*提供的函数可以全部实现,用libgtk只能做到功能a、加上libglib、libpango、libcairo这些可以做到功能bc,至于功能d要么自己写要么引入其他的库,这就是qt和gtk开发的常见情景。如果按你认为的,只拿libgtk和libQt*来比较大小,合理吗?
当然我也不指望说服你,毕竟看起来你的“依赖libkf*.so就是依赖kde”这一先入为主的观点都差不多是思想钢印了。
offline 写了: 2023-04-15 7:07 3. 从哪里看出我讨厌 QT, 而喜欢 GTK 了?我从没说过,而是一堆 QT/KDE 的粉丝强加给我的。在他们看来,只要不是 QT 的粉丝,就一定是 GTK 的粉丝。只要没赞美 QT/KDE 的,就是我的敌人
你很喜欢脑补出别人没有的意思。再加上性格上可能有点自卑吧,自然会觉得到处都是敌意。
offline 写了: 2023-04-15 7:07 4. 用基于 C 语言的 GTK 开发比用基于 C++ 语言的 QT 更痛苦,那是开发者自身的事情。我当然知道,但跟我的需求没有任何关系,我又没要求开发者采纳我的需求. Fcitx5 的教主以及教徒用此来攻击我,说我根本不知道开发人员有多艰辛,逻辑在哪里?
他们不是在指责你不知道开发人员的艰辛,而是觉得你这种是属于盲目追求轻量,没有意义。就像你在另一个帖子里拿apluse代替pulseaudio一样,表面上看,apulse这个小巧的“计算器”就能满足你的要求,但实际上呢?有些程序就是需要“计算机”上的东西。
offline 写了: 2023-04-15 7:07 5. 假如你开发一个 Web 服务器软件,依赖了 libX11. 被他人拒绝使用,认为服务器上的东西不应该依赖 GUI 的库。然后你说:“依赖 libX11 不等于依赖 XOrg Server. 并不需要在服务器上开启 X Server, 只是多了几兆大小的库而已。因为服务器上缺乏一些好的库,而刚好 libX11 里头有些函数可以大大加速我的开发。你这个服务器上的运维人员根本不懂得怎么开发软件,一个民科在大放厥词……” 逻辑在哪里?当然这个例子在现实之中不会存在,因为服务端软件禁止依赖 libX11 是一种大众心理,你没那个胆量为了自己便于开发而去得罪大众心理。
你如果不是开发者,没什么开发经验,就不要去想象开发相关的事,更不要去自作聪明臆测开发者的想法。
如果一个程序依赖libx11的函数,那么它必然会把xserver作为运行时的依赖。不存在你想象的“依赖 libX11 不等于依赖 XOrg Server. 并不需要在服务器上开启 X Server, 只是多了几兆大小的库而已”。
我当年刚学qt的时候,就正好开发过一个没有图形界面的程序跑在服务器上。因为当时不太懂,错误地让那个程序间接依赖了libx11和xserver。我后来弄明白了是怎么回事,把相关的依赖去掉,也不是你臆想的害怕“得罪大众心理”,而是基于现实的安全性稳定性等考量。
offline 写了: 2023-04-15 7:07 我当然不指望你们会认错,写那么多只是希望其他有小众需求的人有勇气说出自己的想法,不要因为被群殴就妥协。一伙人对我群起而攻之的唯一原因就是我的小众需求让他们感到不爽,他们渴望享受那种压制别人的快感。
你受到群嘲的原因不是因为你的小众需求让人不爽,而是明明不懂却在那里大发谬论,还不听劝。相当于你看到煤炭每吨单价比火箭燃料便宜,就嚷嚷着火箭该烧煤炭。别人说的热值、比冲等专业术语你又不懂,你越拿报价单来证明你的观点,就越显得是个小丑。
另外你觉得别人是在“渴望享受那种压制别人的快感”,那么你自己这么固执己见又是不是在享受众人皆醉我独醒的快感呢?
offline
帖子: 42
注册时间: 2012-02-06 11:26

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

#18

帖子 offline » 2023-04-18 17:24

astolia 写了: 2023-04-18 15:24
offline 写了: 2023-04-15 7:07 2. 将 GLib 这种库强行算作 GTK 的一部份,合理吗?因为 GLib 和 GTK, GNOME 的开发人员有很大的交集,就将它们捆在一起?如果真要捆在一起,也不会独立成一个项目了。
我上面说过,你不是开发者,你的理解和一般开发者的认知存在很大区别。
offline 写了: 2023-04-15 7:07 3. 从哪里看出我讨厌 QT, 而喜欢 GTK 了?我从没说过,而是一堆 QT/KDE 的粉丝强加给我的。在他们看来,只要不是 QT 的粉丝,就一定是 GTK 的粉丝。只要没赞美 QT/KDE 的,就是我的敌人
你很喜欢脑补出别人没有的意思。再加上性格上可能有点自卑吧,自然会觉得到处都是敌意。
offline 写了: 2023-04-15 7:07 4. 用基于 C 语言的 GTK 开发比用基于 C++ 语言的 QT 更痛苦,那是开发者自身的事情。我当然知道,但跟我的需求没有任何关系,我又没要求开发者采纳我的需求. Fcitx5 的教主以及教徒用此来攻击我,说我根本不知道开发人员有多艰辛,逻辑在哪里?
他们不是在指责你不知道开发人员的艰辛,而是觉得你这种是属于盲目追求轻量,没有意义。就像你在另一个帖子里拿apluse代替pulseaudio一样,表面上看,apulse这个小巧的“计算器”就能满足你的要求,但实际上呢?有些程序就是需要“计算机”上的东西。

你如果不是开发者,没什么开发经验,就不要去想象开发相关的事,更不要去自作聪明臆测开发者的想法。
如果一个程序依赖libx11的函数,那么它必然会把xserver作为运行时的依赖。不存在你想象的“依赖 libX11 不等于依赖 XOrg Server. 并不需要在服务器上开启 X Server, 只是多了几兆大小的库而已”。
我当年刚学qt的时候,就正好开发过一个没有图形界面的程序跑在服务器上。因为当时不太懂,错误地让那个程序间接依赖了libx11和xserver。我后来弄明白了是怎么回事,把相关的依赖去掉,也不是你臆想的害怕“得罪大众心理”,而是基于现实的安全性稳定性等考量。

你受到群嘲的原因不是因为你的小众需求让人不爽,而是明明不懂却在那里大发谬论,还不听劝。相当于你看到煤炭每吨单价比火箭燃料便宜,就嚷嚷着火箭该烧煤炭。别人说的热值、比冲等专业术语你又不懂,你越拿报价单来证明你的观点,就越显得是个小丑。
另外你觉得别人是在“渴望享受那种压制别人的快感”,那么你自己这么固执己见又是不是在享受众人皆醉我独醒的快感呢?










我只是不希望多增加额外的依赖,但没说依赖了 KDE 的相关库就等于依赖了整个 KDE 桌面环境. KDE 是 KDE, QT 是 QT.

Fcitx 的作者首先设置了一个假想敌:“那家伙想用 GTK, 而不用 QT, 并且他非常无知地认为 GTK 比 QT 更小,现在我发一篇博客来驳斥他的无知……”

实际上我根本没排斥过 QT, 只是不希望依赖 KDE 的相关库,同时也希望既提供基于 GTK 的配置工具,也基于 QT 的配置工具,这样才显得“桌面中立”。

我只是 Fcitx 的使用者,将其当作一个“黑箱”,不去考虑内部实现。他在博客里显然不是“基于功能来比较”,而是统计了两套库的大小,说两者所占的磁盘空间差不多。这完全不是事实呀,然后我就针对这点来驳斥。你们何必牵扯到内部如何实现呢?


这是作者在博客里的原话:

而且时常大家会对 Gtk 和 Qt 在磁盘容量上有一些错觉,认为 Gtk 是 C 所以就「light」,编译出来的代码量就要小得多。

他对两者所占的磁盘空间进行统计,统计结果两者所占的磁盘空间却相差一大截。



你确定我不是开发者?当然我的编程水平确实整体远不如你,但不等于你可以随意蒙骗我。如果你只是简单地调用 libX11 里头的几个 utility 类型的普通函数,完全可以做到无须启动 X Server 就可以运行。



你说的:

你看到煤炭每吨单价比火箭燃料便宜,就嚷嚷着火箭该烧煤炭。别人说的热值、比冲等专业术语你又不懂,你越拿报价单来证明你的观点,就越显得是个小丑。


那完全是你自己强加给我的吧?我在上面说了,我只是 Fcitx 的使用者,将其当作“黑箱”,不想去讨论内部如何实现、用什么库更便于开发,而仅仅从外部来讨论如何让它更简单。你从我的原话(包括 suse 论坛里的主贴和跟帖)里找出我哪里去讨论了内部实现,我一直只是从外部角度来分析哪个更简单,而你们却总是要用内部实现来转移话题。


建议你去改变这些:

http://www.suckless.org/

的作者,他们的原则是: quality software with a focus on simplicity, clarity, and frugality. 就是只开发简单软件,他们对臃肿的软件深恶痛绝。你跟他们说:“你们不懂开发才会喜欢小巧软件。只能从外部看到软件所占的磁盘空间,却不懂得哪个更适合用来开发”。
fuhuizn
帖子: 948
注册时间: 2006-01-06 22:55
系统: ubuntu
联系:

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

#19

帖子 fuhuizn » 2023-04-20 10:48

用QT编写GUI比GTK体验好太多了,用GTK真的很麻烦,这一点要理解作者。
回复