fcitx / fcitx5-chinese-addons

Addons related to Chinese, including IME previous bundled inside fcitx4.
GNU Lesser General Public License v2.1
200 stars 26 forks source link

有没有可能去掉qt webengine的依赖 #12

Closed xlucn closed 4 years ago

xlucn commented 4 years ago

我搜了一遍,貌似使用webengine的地方只有引入在线搜狗词库这里(我在虚拟机里试用的时候点击链接还是闪退的,不知道是没完成还是bug)。 从我自己的情况来看,我用的软件里是没有依赖这个webengine(之前用过qutebrowser,现在也不用了),可能大家用到它的都不会太多。而我安装qt webengine占用了140MB+的空间,基本就是装了一个chromium内核。 因此我觉得还不如在系统默认的浏览器中打开搜狗词库的网站,提示用户手动下载,再从文件导入。即便对于一般用户也不算繁琐。

xlucn commented 3 years ago

@wengxt 上面提及这里的archlinuxcn源的issue问到打包问题了,今天再打扰作者追问一下这个问题。

按照我仅有的一点点编程能力看,目前是否要用qt5-webkit或者qt5-webengine,是取决于发行版的打包人员怎么利用cmake里的一些设定。并且现在默认是使用qt5-webkit,archlinuxcn的包也是这么打的。

我的期望是,能做成arch打包里optional dependencies这样的关系,可能就是build的时候自己检测有没有装上面这些依赖的库,有了就用,没有就不用,而不是固定下来。我不清楚的是,这个事情是交给打包人员做,还是需要作者你在程序里实现。想问下作者的看法。

wengxt commented 3 years ago

在硬盘这么大的年代,纠结这个只是徒增开发者负担。

WhiredPlanck commented 3 years ago

@wengxt 上面提及这里的archlinuxcn源的issue问到打包问题了,今天再打扰作者追问一下这个问题。

按照我仅有的一点点编程能力看,目前是否要用qt5-webkit或者qt5-webengine,是取决于发行版的打包人员怎么利用cmake里的一些设定。并且现在默认是使用qt5-webkit,archlinuxcn的包也是这么打的。

我的期望是,能做成arch打包里optional dependencies这样的关系,可能就是build的时候自己检测有没有装上面这些依赖的库,有了就用,没有就不用,而不是固定下来。我不清楚的是,这个事情是交给打包人员做,还是需要作者你在程序里实现。想问下作者的看法。

在硬盘这么大的年代,纠结这个只是徒增开发者负担。

@OliverLew 承上言,一味追求 Lightweight 和 Minimalist 没有意义,工具在于好用而不是轻量。在这个资源丰富、快节奏的年代,(容我不客气地这么讲:)像小老太婆一样束手束脚小碎步,不仅增加开发者负担(或开发成本),也容易让用户积累不满。

CoelacanthusHex commented 3 years ago

@wengxt 上面提及这里的archlinuxcn源的issue问到打包问题了,今天再打扰作者追问一下这个问题。

按照我仅有的一点点编程能力看,目前是否要用qt5-webkit或者qt5-webengine,是取决于发行版的打包人员怎么利用cmake里的一些设定。并且现在默认是使用qt5-webkit,archlinuxcn的包也是这么打的。

我的期望是,能做成arch打包里optional dependencies这样的关系,可能就是build的时候自己检测有没有装上面这些依赖的库,有了就用,没有就不用,而不是固定下来。我不清楚的是,这个事情是交给打包人员做,还是需要作者你在程序里实现。想问下作者的看法。

当开发者把这个做成一个编译选项的时候,这个责任就不再是开发者的了,请找打包者

xlucn commented 3 years ago

@wengxt @whriedplanck 好的,谢谢二位的回复。我确实属于相对比较喜欢追求轻量的用户,而这种用户确实比较小众。我完全尊重开发者和其他用户的意见,其实我也并无意强迫开发者。如果我的请求同样符合开发者的意愿,那我很幸运,如果开发者不喜欢,我也没有任何权力表达反对或不屑。其实大多数开源界的用户与开发者的关系就是这样的,是吧。

wengxt commented 3 years ago

这种道理是显而易见的,假设是编译时可选,那么对于二进制发行版来说几乎肯定是必须开编译依赖,除非是 Gentoo 那种可以自选 USE。 既然编译时启用了,还要在运行时可选,有两种选择,一种就是虽然编译了,但是就写成 opt,那正常安装的用户就会发现某个地方无法启用某个功能,点了也无效果,也不知道是什么错误。不是所有用户都会去看什么 opt depends 用什么的。 又或者就是把负担加到开发者身上,非要在运行时去检测某个依赖,那代码就变得很复杂,在这种本来也不需要实现类似插件的地方多实现一个插件系统,或者强行 dlopen 但是可能引入更多的问题。并不「划算」。

更换 webengine 到 webkit 本身是有一定现实意义的,一些发行版认为 webengine 因为用了 chromium 的关系不够 “free”,根本就没打包 webengine。其次就是在用 webengine 的地方有时候会因为显示/opengl 的问题导致随机的 bug,作为使用这个 qt 库的”用户“来说,准备 webkit 的替代作为 workaround 也是可以理解的。并且更早的时候本来这个功能就是在几年前从 webkit 换到 webengine 的,因为 qt5 官方没有 webkit,需要进行修改的代码量不大。

CoelacanthusHex commented 3 years ago

既然编译时启用了,还要在运行时可选,有两种选择,一种就是虽然编译了,但是就写成 opt,那正常安装的用户就会发现某个地方无法启用某个功能,点了也无效果,也不知道是什么错误。不是所有用户都会去看什么 opt depends 用什么的。

我认为这是最终用户的基本责任和使用能力

wengxt commented 3 years ago

@ayalhw 我还见过一大堆会因此来给上游报 bug 的。不会来报的,可能就换掉不用了 真实的平均用户不是你也不是我

xlucn commented 3 years ago

我自己使用过一些软件,所以才有了这样的请求想法。当然,我下面举我自己的例子只是想作为一个用户说明我的视角,我已经完全理解并接受开发者的选择。

我用过screenkey,在屏幕上显示按键的,它在arch的包就选择性依赖slop,后者单纯是用来让用户手选一个矩形范围并返回。那如果slop没装,就会弹出错误提示没有slop,用户就无法使用这个小小的功能来指定窗口位置。想用的话,就要自己去装。

从上面作者的回复来对比看,我了解到可能实现选择性依赖可能在不同的项目、不同的功能上的难度是很不一样的;针对不同的目标用户,对追求最大程度的灵活性与追求最大程度的用户友好性之间的权衡也是不一样的,比如作者提到的不会看opt dep的用户,在fcitx的用户群体中想必会很多,这一点很难照顾;最重要的,开发者的个人的开发习惯和喜好更是不一样的。

我作为没有开发经验的用户,提出的意见和请求肯定很受自己使用习惯的影响,有些时候没有可行性也请见谅。

wengxt commented 3 years ago

具体的例子和具体的例子不同,例如你说的这个 slop 就是单纯的作为一个命令,是容易进行动态检查的。 反过来说,假设有一天 screen key 支持了 wayland,需要直接调用对应的 C API,你就很难让它在同一个 binary 说我去掉 wayland 的支持。