怎么感觉 PyQT 很少有人用，是不是被低估了

50 条回复 • 2023-06-25 10:47:36 +08:00

1

liantian

2023-06-23 18:05:42 +08:00 via iPhone

学的人少…因为职业的前端工程师，只要会一套 js 的框架，就可以 Electron+flutter 移动端桌面端全平台通吃…。

全栈才会根据自己习惯的语言选择 pyqt 什么的。

久而久之，环境就这么变了。

2

roundgis

2023-06-23 18:11:39 +08:00 via Android

工業用途也不少不過和 web 前端那一幫人交集不大

3

hsfzxjy

2023-06-23 18:12:50 +08:00 via Android

直接用 qt 的应该比较多

4

youthfire

2023-06-23 18:17:37 +08:00 via iPhone

5

我用的 PySimpleGUI 。反正当时 QT 文档看不明白，无从入手，而 PySimpleGUI 秒懂。

5

Syiize

2023-06-23 18:24:28 +08:00 via Android

1

pyqt 打包后体积会非常大，不是特别依赖 Python 的一些功能的话，qt 会小一些，而且打包还方便。

6

tensorzhang

2023-06-23 18:25:30 +08:00

pyqt 打包费劲，直接上 c++了。

7

iugo

2023-06-23 18:34:10 +08:00

如果拿出来 Electron 作为对比, 那么就应该考虑 Tauri.

8

Aoonthetop

2023-06-23 18:34:21 +08:00

直接用 webview 不比 pyqt 好用

9

iorilu

OP

2023-06-23 18:36:58 +08:00

@iugo 我意思就是除了套浏览器的那几个，其实唯一选择就是 qt

10

aaniao002

2023-06-23 18:38:03 +08:00 via Android

qt 老牌桌面应用，开源啊，没软文啊，你当然觉得不出名，打开 wps 看看用了什么库。electron ，web 方向跨平台，目前趋势嘛。

11

wxf666

2023-06-23 18:38:06 +08:00 via Android

@Syiize 还好吧。看过知乎上有大佬，用嵌入式 Python 环境 + 手工裁剪 PyQT 5 ，最小能打包成 14MB 即可

12

Jirajine

2023-06-23 18:38:20 +08:00

qml 还行吧，也是小众。老一套的 qt 太落后了。

13

iorilu

OP

2023-06-23 18:41:42 +08:00

@wxf666 以前可能体积是个问题，现在网速电脑硬盘越来越大，百把 M 的软件根本不是问题了

就算手机软件也都几百 M 了

14

hefish

2023-06-23 18:50:45 +08:00

因为这几年互联网大爆发，搞 web 的实在是多。。。
而 QT ，其实一直都存在，只是用不到 web 上。。。

15

Danfi

2023-06-23 18:56:03 +08:00 via Android

pyqt 界面做好看有点麻烦

16

jsq2627

2023-06-23 18:58:46 +08:00 via iPhone

想做好看的 UI ，特别是那种动效丰富的，到头来发现还是 web 平台最方便，轮子最多

17

SenLief

2023-06-23 19:09:54 +08:00

主要是现在前端横行，出活快。再就是 python 打包体积太大了。

18

iorilu

OP

2023-06-23 19:25:49 +08:00 via Android

1

@jsq2627 问题是大多用户其实不在乎界面多好看啊，很多时候就是要个 ui 方便用户用，毕竟不是个个程序员可以用命令行

其实大多软件就是命令行接口套个壳就有很多需求

19

zhangshine

2023-06-23 19:34:48 +08:00

在意界面的人也不少，你看今天的帖子 /t/951012 里面在意界面的就不少

20

NessajCN

2023-06-23 19:46:02 +08:00 via Android

不如原版 cpp qt 好用

21

muooOOO

2023-06-23 20:03:46 +08:00

跨平台下想要性能用 C++。想要出活快并且 UI 过得去，那就 web 。
pyqt 就很尴尬。。。

22

psyche08

2023-06-23 21:16:11 +08:00

QT 问题有两个，C++门槛比前端高，授权问题

23

totoro52

2023-06-23 22:35:16 +08:00

动不动就上几百 M

24

vincent7245

2023-06-23 22:39:54 +08:00

都用 qt 了，直接 c++写呗，要不然还不如前端一把梭

25

garywill

2023-06-23 22:46:12 +08:00

楼上好多说直接 c++的，我其实最近 c++和 py 两种 qt 用法都有尝试，感觉 c++稍改一点编译太慢了，宁愿 py

26

angrylid

2023-06-23 22:49:09 +08:00 via Android

PyQt 适合于你本来就有个 Python 工程，然后你需要给它加个 UI 的情况。不管怎么说，比 wxWidgets 或者 tk 强多了吧。

另外 2C 产品用 Qt+CEF 应该远比 PyQt 主流。

27

bugfan

2023-06-23 23:11:10 +08:00

刚毕业那会用的 TKinter 写 gui,当时写 gui 的好像 pyqt 用的多

现在果断就用 Electron+Golang 了，无论是开发速度，还是编译速度都是好一点，就是最后编译出来的体积大一点，但是无所谓了

28

0312birdzhang

2023-06-23 23:23:50 +08:00

新的 Qt 使用 qml+js/c++写界面也很简单，主要是学习 qml 需要一些成本

29

shyling

2023-06-23 23:29:47 +08:00

应该是直接用 qt 的多吧

30

statumer

2023-06-23 23:34:13 +08:00 via iPhone

2

PyQt 在 GUI 解决方案这块儿是非常专业的，不是 tk 和其他的一些杂牌框架能比的。
但是 PyQt 和 Electron 相比有这么几个问题：
Qt 的 MVVM 和 js 相比非常落后。Qt 官方有一个 model - delegate - view 的框架，但是写起来复杂且不好用。如果你不用 mvvm 你就自己去计算 ui 的状态转移吧。
Python 本身作为脚本语言性能和 v8 有质的区别。Py 和 electron 都可以加 native 扩展。
Qt 本身对样式和排版的支持远不如 chromium ，你想写个好看的动画和样式还需要自己研究 QGraphics 。当然如果你的审美能接受丑陋界面这倒也无所谓。
关于部署，qt 官方有一个 pyside6-deploy 工具，这东西是对 nuikta 的 wrapper 。但是根据我的踩坑经验这个工具没有任何实用性，这个包装很糟糕也就罢了，nuikta 自身也有各种各样的问题，远不如 PyInstaller 成熟。给我感觉 Qt 官方没有很在乎 PySide 的发展。打包完和 electron 相比体积也没有优势。

31

flyqie

2023-06-23 23:43:57 +08:00 via Android

1

非 py 项目引 pyqt 没意义。。

打包不方便，体积大，开发也不方便。

qt 自家主用 c++，对 py 这边。。哎。

你见过用大公司用 pyqt 写项目吗，我没见过，但我见过一堆用 electron 写的。。生态是大事。

32

flyqie

2023-06-23 23:46:37 +08:00 via Android

@flyqie #31

哦对了，qt 的生态和功能基本都是优先 c++的，要说起来的话，c++ qt 才算名副其实的正统。。

33

ysw

2023-06-23 23:59:00 +08:00

我尝试使用过，感觉有点复杂，除非想用 python 的库，不然 electron 的确方便

34

wangerka

2023-06-24 08:06:24 +08:00

1

我写过好几个 pyqt 的项目，整体感觉是 60%花在写 UI 上，只能有 40%的时间写逻辑，而且 qss 文档也少，写出的 UI 不好看，很难实现 web 那些炫酷的动画。
写一个功能一样的应用，用 pyqt 需要的时间可能是 web+electron 的好几倍。

35

opengps

2023-06-24 09:03:32 +08:00

各有各的用途，我现在做工控领域，发现不少老程序都用的 Qt ，写这种程序的人往往不怎么热衷分享，毕竟真用起来都是在企业内网，谈多了都可能涉及到暴露一些企业信息的地方

36

iorilu

OP

2023-06-24 09:45:47 +08:00

我个人觉得 electron 的 ui 是带 web 的风格，这不是完全 native

当然这是我的想法，我如果开发桌面软件，想更 native 一些

另外性能也不是完全一样把

37

HiCode

2023-06-24 11:45:42 +08:00

win form 类型的 gui 框架，在这一场竞争中输给了 html+css+js

不管是 qt ，还是 delphi/lazarus ，还是微软家的 Windows Forms ，原先那种桌面 gui ，都败了。

去看 gui 框架的发展，趋势非常明显了。

38

NoOneNoBody

2023-06-24 11:50:50 +08:00

我也喜欢 native ，一个自用的东西从 pyqt4 写到 pyqt6 ，BS(browser-server)和 CS(client-server)还是有点区别的
一些细微的点的区别，让最终整体表现相差很大，有点蝴蝶效应的意味(混沌理论？)

先是证书版权问题，这让 qt 商用环境有点复杂，老实说我都没搞清，只是我没商用甚至没公开发行就不理会而已
大公司恐怕要让法务研究一遍证照问题

然后是 client-UI 本身就是难点，它面对的是人，因为事件驱动，但人的行为是无限的，这造成不可预想的用户行为太多，上面有说 UI 工作占了 60%的，我觉得说得少了，UI 应该是可以单独构成项目了
例如一个 tableview 展示 pandas-dataframe ，多列排序（含拼音排序和浮点数排序），这么简单的需求，工作量就很大了
数据表格，web-ui 是用户选好排序的列，提交，后端计算然后跳转页面（或整页刷新）；而一个 client-UI 做整个界面刷新是很奇怪的，只能做控件刷新

最后，客服问题
用户对 web 有种自动降低需求的感觉，看到是 web 就没有那么多要求——“能看清就行”。例如一个文件名有特殊字符不能读，web 提交一般不会崩，返回错误，用户的接受度高，会自觉调整适应；但纯 client 先要解决不能崩，然后返回错误，但用户也会不接受
这是某种潜意识引发的，bs 的话，用户默认数据在 server 端计算，提交数据需要适应 server 要求，会把 server 按甲方看待；而 cs 的话，用户则认为软件(UI+后端一体)在本地，软件的表现应该一次处理所有问题，没弄好就是 bug
client-UI ，不可预料的用户行为太多，有些仅仅只是操作顺序问题，用户不遵循这个顺序就会出现问题，并不是 bug ，但用户不这么认为
个人项目基本难以兼任“客服”，导致做纯 client 的项目本身就少，更别说 pyqt 了。pyqt 缺少 py 文档，学习成本其实要同时看懂 C++语法的文档，还要懂 python （废话），比单纯 C++ QT 还要难。还好现在有人在 github 做了纯 py 语法的 pyqt 文档了

总的来说，web-UI 和 client-UI 的区别是，web-UI 是提交“参数”，后端做数据筛选和处理，步骤是单线程的（并发在 server 而不在 UI ）；而 client-UI 是交互数据，UI 操作时也要计算数据，还要防止界面 freeze ，是一个协程 /多线程工作

现在越来越多 web-UI 就是要把事件驱动简单化，让不可预料的用户行为大幅度压缩，直到这些“不可预料”达到极少数就可以忽略不理会了，舍弃少数“异端”客户，压缩工作量（成本），获取更大利润

39

iorilu

OP

2023-06-24 14:59:47 +08:00

@wangerka 我不这么看

我不想用 web 就是因为 web 这么多年一直没有稳定下来，不停的要学新东西换新东西

我只想用最简单的方式做个能用的界面

而且 web 你默认啥也不配比如 css 的，是没法用的

但 qt 你啥也不弄出来的界面也能用，而且完全 native 的

再加上 qt 这么多年的历史，学了一直能用，也不用一直搞新东西

pyqt 最大问题确实是没啥文档，方法是直接运行例子，模仿修改就行

40

HankLu

2023-06-24 15:32:41 +08:00

其实我用 pyqt5 开发了很多 Windows 软件，不过都是自己用，别人用不上

41

duan602728596

2023-06-24 15:36:13 +08:00 via iPhone

不好用，以前要写 GUI 用过一次。
首先对于 UI ，和 web 可以随意修改样式相比，pyqt 就差很多，甚至布局都不是自适应的。
其次 pyqt 如果执行方法不在子线程，很可能会阻塞 UI ，导致无响应。
还有就是 web 可以随意开子线程，随意存储数据，随意开多窗口，随意用 Electron 提供的 native 方法。开发编译跨平台。他已经帮你解决各种跨平台问题，让你只开发功能就好了。
所以费力不讨好的开发方式自然就比不过轻松的开发方式了。