![](/style/images/good.png)
![](/style/images/bad.png)
C++ 和 C# 哪个容易开发出用户体验好(占用资源小&好看&稳定&反应快)的...
source link: https://www.v2ex.com/t/841554
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
C++ 和 C# 哪个容易开发出用户体验好(占用资源小&好看&稳定&反应快)的跨 macOS/Windows 平台的桌面程序?
theklf4 · 1 天前 · 4349 次点击Electron 不考虑,没见过用 Electron 写的用户体验好的程序,公认优化好的 VS Code 启动也很慢,剩余内存一不够就卡得要死。
目前是有一点 C++ Qt 和 C# WinForm 开发经验。想写一个桌面程序,因为比较喜欢 C#(很多功能都不用自己实现,而且我更熟悉一点),而且听说 C# 的 Avalonia 框架可以用来非常方便地开发好看的跨平台 GUI 程序,于是打算用 C#来写。但 Google 了一下,很多人说 Avalonia 在 macOS 上有很多 non-native 行为,例如复制键变成了 Control-C 而不是 macOS 默认的 Command-C ,而且不是很稳定,经常崩溃,也没有什么知名开源项目在用,资料不好找。想问问 C++ 和 C# 哪个容易开发出用户体验好(好看&稳定&反应快&占用资源小)的跨 macOS/Windows 平台的桌面程序?或是还有什么更好的方案?
好看很重要,最好能方便地实现一些过渡动画。
duke807 1 天前 via Android
後台程序可以是 python 、go 等等不限。
u823tg 1 天前
darklights 1 天前 13
条件反射般推荐 Flutter 写桌面程序的,我赌 5 毛,连搭个环境写 Hello world 都没试过。
duke807 1 天前 via Android
而只調用系統瀏覽器,相當於瀏覽器增加了一個 table ,可以只增加很少內存佔用。
(關於 qt ,我曾經在嵌入式系統,使用 qtwebkit 還是 qtwebengine 記不清了,寫了一個極簡瀏覽器,它只負責打開一個本地 URL 呈現界面。好處是系統上電後全屏運行我的 h5 程序,不需要運行桌面環境。)
duke807 1 天前 via Android 1
性能方面大多數場合也夠用。
專業領域,還是 C/C++ 比較快,譬如開源跨平台的畫 pcb 的 kicad ,用的是 wxWidgets 圖形庫,口碑比 qt 好不少。
3dwelcome 1 天前
感觉不能吧。不都是用 obj-c 或者是 Swift 开发的。
微软已经放弃 C++的界面库了,全面推用 C#的 WinForm 。C++写算法可以,写界面估计不先包装个几层,还是很难写好的。
话说我在用 Electron 写桌面程序,开发体验感觉是真的好,也可能我本身就是前端缘故,如鱼得水,2333 。
duke807 1 天前 via Android 1
用完全開源的 wxWidgets 可以使用 c++ 寫出跨平台且原生界面的 gui 程序,可以看一下 kicad 6.x 的各平台截圖,或者下載感受一下界面。當然也可以使用 C# 和 python 寫 wxWidgets 程序。
而且 wxWidgets 的版權也比 qt 好很多,qt 越来越不行了。
duke807 1 天前 via Android
kicad 是開源免費的軟件,你可以下載體驗一下。
3dwelcome 1 天前
我个人觉得嘛,就算 C++工程,也还是应该把界面部分独立出去。尽可能把界面逻辑和程序逻辑分离,要不然代码会很乱,非常不好移植。
QT 和 wxWidgets 的语法,都是语言强关联的,这样并太好。你对比一下前端的模板式界面编程,都是必须先编译的,把界面模板编译后得到双向绑定的界面代码,控制起来要灵活很多。
3dwelcome 1 天前
C++里 UI 写复杂后,代码也是一大堆。要不就抽象出去,要不就用直接用配置脚本来驱动。但是这样的话,也相当于搭建了一个简易的 DSL(domain specific language)。
所以从我个人角度来看,UI 应该是不限语言的。
duke807 1 天前 via Android
我覺得對性能要求不高的還是直接用 html5 最方便。
對性能要求高的,可以 wxWidgets 內置 webview 負責性能不高的模塊,可以跑 js ,對性能要求高的部分用傳統的方式。
而且傳統方式也有界面 designer 工具,可以生成代碼。
3dwelcome 1 天前
QT 的学习资源多。大厂 QT 就和前端里 React 地位一样,团队作战肯定优先选择最主流的框架。
除非是一个人开发,进度不紧不慢,可以让你慢慢学。
3dwelcome 1 天前
duke807 1 天前 via Android 1
wxWidgets 真的不弱,也很老牌,我以前沒把它當回事,一直覺得 qt 才是 no.1 ,後來也是通過 kicad 才知道 wxWidgets 比 qt 好,kicad 現在算是電子行業的主流軟件了,除了是極客和開源社區的唯一選擇之外,企業用戶也在大規模使用。
與之對比的是用 qt 寫的 eagle 畫板軟件,用戶基本上都轉用 kicad 了。
瀏覽器如果界面交互用 wasm 做,那麼也就享受不到 h5 做界面的好處了,wasm 一般不是拿來做界面交互的,頂多做一些波形之類的展示。
3dwelcome 1 天前
这样的话,就很不好把界面部分作为独立模块,给完全独立出去。也就是我说的,最好的开发界面方式,应该是 filecxx 那种 sml ,用 DSL 来写。QT 至少有 qml ,不说功能对比,单从后期代码维护上,QT 是优于 WX 的。
其实 2022 年了,语言混编才是王道。死磕一种语言,真没什么前途。
3dwelcome 1 天前
"瀏覽器如果界面交互用 wasm 做,那麼也就享受不到 h5 做界面的好處了"
我在 wasm 里内嵌 React 之类的 JSX 来声明界面,代码需要编译后才能用,我自己都觉得挺奇葩。
反正代码能运行就行了,管那么多。
duke807 1 天前 via Android
不過 qt 不是原生圖形控件,這一點也不如 wxWidgets 。
@3dwelcome 傳統 gui 也是可以把界面做為獨立模塊的,譬如寫一個獨立的控件,整體 gui 也是可以獨立的,你自己做好區分就可以,有些代碼只負責前台,有些代碼只負責後台,明確前後台的通訊管道。
而且,我覺得 qml 這種的效率和 html 差不多,為何不直接用 html ,不用重複學習,調試還方便。做好的 html 可以用多種途徑呈現。
wdhwg001 1 天前 via iPhone
一定要成熟稳定的原生跨平台的话,或许可以跳出来试一下比较传统的 lazarus 。
3dwelcome 1 天前
CSS 太复杂了,需要套一层 webview 才能用。好一点的 webview ,体积都不小,这是楼主考虑的最大问题。
"傳統 gui 也是可以把界面做為獨立模塊的", 这点要在软件一开始设计的时候,就考虑清楚。我真不觉得你能把一个和 wxwidget 强关联的软件,把 wx 整个剥离出去。wx 使用方便的代价,就是强入侵性。
有人喜欢这种,我是不喜欢的。我喜欢每个模块都能随便替换,比如游戏开发,你 DirectX, OpenGL 都是可以随便换的。
neoblackcap 1 天前
然后跨平台,C#也有一些界面库,但是好不用就难说。
Qt 在这方面无论是稳定还是界面的好看,都相当出色。哪怕协议也是有 LGPL 让你选。开发商用软件都没问题。
其实还有第三条路,那么就是你自己写一个。使用一些图形库,直接写界面库,效率贼高,而且可以随便迁移(只需要写一个 render adapter ,基于 IMGUI ,帧数还能上升到 60fps 以上),这方面的例子就是 sublime text
exploreexe 1 天前
你要想在 Mac 上流畅,按照苹果的尿性还是得上原生。Electron 这玩意开发的东西,我个人感觉能用,但是谈不上好用。
leyviw 1 天前 via iPhone
cmdOptionKana 1 天前
而且,Electron 还能让 Linux 用户受惠,没有 Electron 的时候 Linux 用户直接被忽略不计。
pengtdyd 1 天前
1.futter desktop 目前尚不成熟,需要自己写插件,有些功能不完善
2.原生虽然效率,速度,占用都不错,但是现在的个人 pc 早已不太需要考虑这些问题,从产品的角度来说,速度快永远不是第一考虑的事项
3.electron 经过这么多年的发展,nodejs 的生态已经可以覆盖几乎所有的场景,想用直接调用别人写好的包就好,开发效率高
4.electron 可以很好的贴合前端技术栈,这一点仁者见仁智者见智,至少对于企业来说,选择统一技术栈,更有利于团队的技术发展
WebKit 1 天前 via Android
ZSeptember 1 天前
看起来你还是想用 C# 的,那就看看 MS 官方的跨平台框架吧,我记得有好几个,Xamarin ,MAUI
我自己的话,没有 C# 背景,如果自己的应用,会选择 flutter
secondwtq 1 天前
为什么不用 HTML 用 QML:这个锅其实 Web 要背一半,HTML 背另一半。Web 的设计是在沙盒里运行,所有的 API 都要包一层,这就是说在 Web 平台上是无法直接访问到 native 上的 API 的。经过 Web 封装的 API 开销更高,功能更落后,基本上只有个下限。前两年前端各种“前端也可以 XXX 了”,实际上这些在前端之外的领域都不算什么。当然如果不在浏览器里跑可以自己做 binding ,但是还是比 native 麻烦。HTML 的锅是它本来是用来做文档的(“Hypertext”),不适合直接用来做“Application”,现在能做是后来各种补丁整出来的。QML 很明确一开始就是做 application 的。
另外你在个别行业看到的现象,需要个别去分析。技术对更大的东西的直接影响力很有限。实际问题要考虑更多技术之外的东西。
比如我在 VFX 行业看到的现象就是以前每个软件都有一套自己的插件开发技术,但是逐渐统一到了 Python+Qt 的组合。我能因此推导出 Qt 南波湾么?
但同时发生的另一个现象是 Blender 迅速崛起,彻底火出开源圈。就连现在 PC 硬件评测,以前跑 CINEBENCH ,现在也要跑 Blender Benchmark 。Blender 用的不是 Qt ,它自己写了一套界面库。能不能说他这个界面库比 Qt 更好呢?大概也不能。Blender 里面照样一堆老旧设计和屎山代码,它能火就是因为它开源,并且 somehow 一直运营的很不错,后来基本上除了已有专有套件的开发者和其死忠粉之外,所有人都认识到这东西能有好处,所以它花了十五年从默默无闻最后混成了 CG 圈的 Linux 。
IM 是另一个例子,小而美是技术最好的 IM 么?大概不是,但是在个别地区它确实是最流行的 IM 。
nicevar 1 天前
我试验过很多的技术选择,以前用 delphi/vb/vc+mfc/java+awt/swing/swt ,后面用过 Lazarus+Pascal/Codeblocks+wxWidgets/javaFx ,我就想说框架就选择最成熟的,否则那不叫开发,那叫踩坑,项目开发到一半发现有些问题无法解决然后推翻重来?这种公司我真的见很多了。
g00001 1 天前
而且 “桌面软件”是一个很大的概念,具体到是什么桌面软件适合的开发工具都不一样,像用 C# 开发的桌面软件,往 ILSpy 里一拖源码就可以导出来,这要有心理准备。现在 Electron 也是被滥用得太狠了,网页套壳的程序,那确实 Electron 、WebView2 这些都没问题。但是有很多软件并不一定适合用 Electron 之类开发,像录屏软件 Gif123 下载体积只有 720KB ,输入法工具 WubiLex 下载体积只有 960KB ,这种软件用 Electron 就只会增加体积但并不能消减开发成本。
不过如果喜欢在界面上弄很多动画,这最好还是用网页套壳,Electron 其实也过气了,在 Windows 上更好的替代是 WebView2 。
FrankHB 22 小时 41 分钟前
如果你要开发体验的话,那么原则上是 C#,毕竟 Qt 你想用舒服基础姿势水平不低……C#的应用效果其实吃亏,但强在你能用更短的时间折腾出更多不同的方案试错。当然,前提是能实现。
.NET 在框架的意义上吹亏的就是定制起来没 Qt 那么容易折腾(或者说 Windows 以外基本就没稳定实现能用),Avalonia 这种比较新的,具体坑有多少没试过不好说。
Qt 虽然开发效率是个槽点,但是还有 Python 绑定能用(好歹没那么啰嗦),所以也算不上决定性的缺陷(用不用得惯 py 就另说了)。
如果你说做商业项目,要考虑让人接手,那么还是 Qt 忍忍吧。个人项目就随便了。
用不用 QML 看口味。我是不想用,主要是不喜欢各种 ML 那套(有这功夫还不如折腾 SGML+DSSSL 去了)。
Flutter 响应慢和资源占用糟烂是预料之中的,毕竟底层的开发者自己都缺根筋: https://github.com/dart-lang/language/issues/490 。
这类方案的开发者看上去的共同点是没有一个严肃的桌面客户端应用开发背景,整个技术栈的根本设计上就不用指望能解决此类问题,只能“优化”变通。
JS/Electron 之类的软肋也就是这个,而 Dart/Flutter 么,怎么说也不用指望有更好的资源来(各种意义上的)优化了。
大多数玩具也有类似的问题。Rust 实现的算是少数的例外,问题是 Rust 的这类项目都没多少存在感也活不大长,怕是所有第三方方案中最不靠谱的那类,支持就更加看脸了。
@duke807 wx 基本就是个跨平台 MFC ,除了用纯 C++而不需要 Qt 这种 moc 以及性能稍微(在 C++的意义上)更好以外,没什么技术上的优势。工具和开发者社区更不用指望了。
我见过有长期维护的项目从 wx 切换到 Qt 的,比如 TortoiseHg 早期用的 wxPy 后来就切成 pyQt 了。
虽然开发应用未必需要很在意,wx 这类“原生”方案有个致命的架构扩展性弱点:不是所谓的 direct UI 。(依赖 Win32 的 MFC 和 WinForms 也有类似问题,但大部分正常的都没有。)
参考 https://v2ex.com/t/831456#r_11329552 。
@neoblackcap 自己写一个当然是终极方案,不过就只是自己的项目用,太浪费了。
我就糊过能跨 NDS 和 Win32 的,上边 C++能做到都完全看不出是什么平台的(反正比 QtWidgets/QPA 那坨彻底得多),不过自己糊的开发体验嘛……mac 工作量不好估计,反正 Linux 的后端我是坑快十周年了。
imgui 这种 immediate mode 的半残基本也就算图形库了,都不算正经 GUI 库(撑死就是“画界面”外加输入套皮),GUI metaphor 基本都没在 API 体现,要在严肃项目里用还不如自己造轮子。
比起上面说过 wx 是缺乏可扩展性,imgui 这种就差不多没什么架构能被扩展。要从里面拆代码复用,那还不如自己照搬目的纯粹一点的图形库( Cairo 、skia 之类)自己从头搭框架。
@ZSeptember 说 Qt 资源占用多,对也不对。
比起大多数其它 C++方案 Qt 往往因为不必要的运行时元数据访问而确实经常更拉胯,但一般同等经验的开发者写起来不会比用 C#实现的更慢。也就 QtCreator 这样规模的应用比较容易暴露出瓶颈。
更重要的是这里可是把 Electron 都拉上场一起遛了,正经写想更慢实在不大容易。
@wdhwg001 这只是相对其它成熟方案来说的,如果是相对自己糊界面库,这类问题就算不了什么问题,毕竟自己实现也得把这种东西折腾对,还是挺花资源的。
根本让 Flutter 无可救药的是上面说过的 Dart 的思路(同时也适用于 Electron )。
duke807 22 小时 19 分钟前 via Android
至於 TortoiseHg ,我看了一下,大概知道是什麼樣的作者和用戶群。深入融入開源世界的人,基本是不會使用第三方圖形 git 工具的,git 自帶的 gitk 就夠用了。
開源界的軟件都是 linux 優先,其它系統的體驗肯定要稍微差一點,kicad 這麼重量級的軟件在 windows 和 mac 下的表現已經非常好,所以用 wx 應該沒有什麼問題。
FrankHB 21 小时 58 分钟前
(才不是看漏了呢,哼、、、)
如 v2ex.com/t/831456#r_11329552 分析的,所谓“原生”基本只是包袱,而不会是普遍意义上的优势。
首先,没什么最终用户就纠结真的 bug-to-bug compat 程度的“原生”。至少 GUI 用户是感知不到一个动作的响应是不是用 WM_SH*T 还是 signal 还是 std::function 来实现的。
所以,只要实现得了用户不需要分出差异的效果,这里的差别基本就只是对开发者有意义。但这个意义仍然是决定性的,存在高下之分。
根本上,就软件工程的一般方法论来看,实现用户需求的过程的正常方向是自顶向下的:了解主要需求,分解需求然后确定实现方案。
这个意义上,任何软件理想情况下理应都是所谓的跨平台软件,因为凭空依赖平台并不是一般用户的主要需求(用户只是“有啥用啥”而已)。这也跟这里分析的任何 GUI 都天然是所谓的 direct UI 一样。
只有为了照顾可实现性,开发者便宜行事,才添加实现细节而形成路径依赖,导致潜在的方案切换成本。这本质上是一种妥协,是一种 artefact 而不是 intent 。
是否使用所谓原生或者所谓的 HWND 都是这类细节的例子。把这种实现细节泄露到上层的方案中造成混乱的状况乃至坑到开发者自己,是到底,全体开发者的无能或者说失职。
具体来讲,现在需要纠结这方面的选型,直接原因就是 GUI 历史上的实现就很碎片化,导致能产品化的方案也很碎片化;而后来的开发者并没有能力把不同的方案统合起来(加上像 mac 阵营和早年 Windows 开发者都很多刻意搞封闭制造技术兼容性壁垒的),事实上根本没一般意义上跨平台的方案能用( Web 也跨不了资源受限的一些嵌入式设备),所以才不得不去对照具体方案比较优劣计较得失(因为做不到面面俱到)。
想比较彻底地解决这种问题,专业搞 GUI 框架的都搞不定,作为应用开发者自然更加搞不定,这情有可原;但是不正面认识到这只是一种妥协,反过来以退为进,给碎片化继续火上浇油,不说技术上是否绝对正确,那起码算是个自私的方向。
@g00001 这里有个和上面相关的我需要批判的观点。
既然“桌面软件”这么个大概念的实现方案混乱如此,都快要指望全人类命运共同体都不见得能收拾得好了,那么纠结“一拖源码就可以导出来”就不应该强调。
或者说,为了实现刻意藏源码这种不是来自用户而是开发者自己的需求,增加另一个维度上的问题复杂度,这是唯恐天下不乱。
倒并不是说混淆源码的需求就一定是错的。而是说,即便藏起来源码开发者天然有权自决,实现成什么样的效果也是开发者自己负责,但一旦开发者行使这种权利,道义上就有必要需要理解这算得上是在薅市场羊毛,耗费本来就捉急的能系统性解决这类历史问题的公共开发资源。
这方面更应该鼓励的是把商业价值和源代码的可见性脱钩:在商业模式上做到即便随便让人扒源码也不会泄露商业秘密和损害销售,而不是道高一尺魔高一丈搞这种老实的最终用户只会凭空付出开销的军备竞赛。这样对谁都好。
如果能收拾好跨平台弱鸡可移植困难的局面,份额多少也会成为大多数开发者不用再操心的历史问题。
顺带说一下另一个问题:安装包体积和开发体积完全是两码事。安装包大是因为二进制依赖,这些依赖不需要应用开发者修改。而且只要系统自带就看不出来了。这个方面至少.NET 其实相当大,并不比 Electron 省地方。
jjx 21 小时 19 分钟前
第三方组件不能用, 如 devexpress 之类, 性能杀手
而且以前用机械硬盘时, c#/clr 这种东西因为加载东西太多, 速度快不起来, 现在都用 ssd 的, 就没有问题
用 html 又要性能,自然是使用 sciter, 国内有个 miniblink 也可参考
FrankHB 21 小时 16 分钟前
开源世界从来都不会整体认为 GUI 不重要。也没有显著的个体支持这种调调,相反的倒有不少。例如,Linus Torvalds 显然算是你所谓开源世界的一员;你可以参照一下他是否认为 GUI 的缺失对开源世界产品的用户更友好。
所以是否来自开源世界,用户对 GUI 的需求很大程度是共通的。要有差别也只是行业习惯上的问题(许多逻辑用 GUI 只会降低效率);我举例的不属此例。
另一方面,你的说法暴露出你对你所说问题的很大程度的不熟悉。
首先一个事实错误就是 TortoiseHg 并不是所谓的“第三方 gui”,而是 Windows 上默认官方图形客户端。它很早(十多年前)就是随着 Mercurial 官方源一起提供下载的,甚至基本同时发布,只是早年版本号不统一罢了。这和 git/gitk 没本质差异,无非是 gitk 简单到之后直接整合到 git 的 repo 的子目录下一起管理了。
第二,你没看到不同 GUI 的差异。即使是同类的 GUI ,hg 和 git 差异也不小。不管是不是开源世界的,用过不同 DVCS 的用户,不少都认为 git 功能强大,但是命令行设计糟烂。有的用户会自己写脚本包装命令,而 GUI 就是另一种对更多新手用户解脱的方向。(虽说 hg 也有 amend 和 graft 都得 log --debug 才能看的笑话,但总体还是比 git 那么让人火大。)
遗憾的是,不少其它 GUI 也设计得很初级(特别是 git ,命令行的功能多得多,GUI 很多都没实现)。而同样叫做 Tortoise ,TortoiseHg 的 workbench 就吊打 TortoiseSVN 和 TortoiseGit (基本就只是复用了 troitoise 系的图标),功能覆盖度相对也很高,根本就不是一个档次上的产品。抛开 stash/mq 这种底层机制,像 diff/patch/shelves 编辑上的体验就不是一个等级上的,这完全是 GUI 自己设计的差异。
( Atlanssian 的 SourceTree 就照搬了不少设计,和 TortoiseHg 主界面布局相差远不如 TortoiseHg 和 TortoiseGit/TortoiseSVN 差得多。)
至于 gitk ,说白了主要就只是 git log 的 wrapper ,就别提了。真要说的话,界面布局倒是也更接近 TortoiseHg 而不是 TortoiseGit 。
当然,这里的问题和 wx 还没太直接的关系。上面提过,这个问题是关于框架自身的,二次开发框架才会集中体现出来(死活都没法把 WinForms 改成 WPF 一样的无力)。应用开发者用 Qt 代替 wx 也经常有其它更显著的理由,比如工具和社区支持。
FrankHB 21 小时 12 分钟前
( git 让人火大的不只是 CLI 设计,至少还有在一些小版本瞎改文件布局之类。)
duke807 20 小时 56 分钟前 via Android
同時我也反對妖魔化命令行,我認為命令行方便的就用命令行,圖形方便的就用圖形。我寫代碼會用 eclipse 之類的 gui 程序,覺得用 vim emacs 寫代碼的人魔征了。
對於 git ,我一直認為,精通 git 可以提升工作效率,而只會一點皮毛反而降低工作效率,而且總有一天會搞出飛機坑死自己。既然精通 git ,自然使用 git 命令操作 git ,配合 gitk 觀察狀態是最優的方式。
g00001 20 小时 49 分钟前
FrankHB 20 小时 4 分钟前
不过,考虑到拖出源码虽然自己看问题不大,拿来改其实就有一些法律风险,相对明确开源也不算很应当被鼓励。
g00001 20 小时 3 分钟前
前些天还看到有人说用 C# 写的软件写完了才知道别人可以轻松导出源码(包含工程文件),
有一个方法可以试试,用 aardio + C# 开发,操作简单不用花钱,可以阻止 ILSpy 还原代码,可以内存加载 C# 写的 DLL ,生成极小的独立 EXE 文件。
发个例子:
源代码;
import win.ui;
var winform = win.form(text="嵌入 .Net 控件")
winform.add(custom={cls="custom";left=25;top=25;right=736;bottom=274;db=1;dl=1;dr=1;dt=1;z=1})
import System.Data;
import System.Windows.Forms;
var Forms = System.Windows.Forms;
var dataGridView = Forms.CreateEmbed("DataGridView",winform.custom);
var dataTable = System.Data.DataTable("DT");
import System.Type;
dataTable.Columns.Add("名称");
dataTable.Columns.Add("计数",System.Type.GetType("System.Double"));
dataTable.Columns.Add("选择",System.Type.GetType("System.Boolean"));
//绑定数据源到视图
var dataView = System.Data.DataView(dataTable);
dataGridView.DataSource = dataView;
dataGridView.EditMode = 2;
//添加测试数据
var row = dataTable.NewRow();
row.ItemArray = {"王五",123, true}
dataTable.Rows.Add(row);
winform.show();
win.loopMessage();
g00001 19 小时 44 分钟前
呵呵,这么 low 的帖子居然能被你扒出来,那么不顺手扒一下别人怎么回复的吗?
Jacen
————————————————————————————————————
有一个现象无法解释,能学好其他编程语言的,学 aardio 都很快,
很多人告诉我几乎拿上手就会用,比任何编程语言都容易。
而说 aardio 难学的 —— 这些人几乎学不好任何编程语言,
做 aardio 这十几年我看到的喷 aardio 不好学,却能学好其他编程语言的 —— 我一个都没见到。
上次看到博客园的遥月长篇大论的喷 aardio ,然后还刷了几天 C# 的学习心得,其实我很期待他真的能学好一样其他的编程语言,但是一年过去了,他人间蒸发了,C#他学了十几年都没学会,可他就是愿意跪舔 C#。
如果 aardio 精心打磨了 17 年的教程你觉得还不方便让你入门。
如果 aardio 提供的系统而完善的使用手册、库函数手册 —— 你觉得不够容易。
如果 aardio 提供的大量篇幅短小的快速入门教程,从最简单的程序到一步步做出精美的界面,有图文,有视频,涉及到 aardio 的各个方面 —— 你又觉得不够系统。
那没有理由继续为难自己用 aardio 啊,为什么不换一个更好的呢?!更好的编程语言那么多。
如果你对编程教学、鉴别品评编程语言都很有心得,那为什么不对自己好一点,选一个好语言给自己?!
如果你对编程教学极有心得,那为什么不对自己好一点,把这些好的教学方式用到自己身上?!
不是不想改进,aardio 一直在努力倾听和前行,活跃更新了十几年。但是这些地图炮式的吐槽 —— 你自己都没办法用这些方法教好你自己,又怎么肯定用你的方式能教好其他更多的人?!
这是昨天一个用户发给我的感谢信:
------------------------------------------------
感谢 aardio 作者,我是刚开始用 aardio 写界面(实在不想用 pyqt 了),python 写数据处理业务,感受到了 aardio 的强大和奇妙。我想把 python 数据处理过程的信息反馈到前端界面中,《这回让我们把 Python 玩出花来》看完后,用了几分钟搞定!!!实在令人惊讶 aardio 的强大!!!再次感谢 aardio 作者的奉献!!!
------------------------------------------------
他才刚接触 aardio 几分钟而已,看了一个简单的教程就用 aardio 写出了自己想要的软件。
有不计其数的用户学不好其他编程语言,却学好了 aardio 。
luohexi
————————————————————————————————————
我是非专业的,疫情以来这两年就想做点文件处理的工具,主流软件都摸索了一遍,今天发现了 aardio ,学了一天就整出来了一个工具,正是我想要到效果。真是相见恨晚啦,太感谢作者大神了,中国人的思维太了不起了。功能强大而直观,不像所谓到那些主流语言弯弯绕太多。
duke807 19 小时 39 分钟前 via Android
java 寫的 gui 的界面經常卡死,曾經用 quartus 的 ip wizard ,現在用的 stm32cubemx 都是經常卡死,resize 窗口后,需要重新繪圖的區域變成白色。把 ibus 輸入法關掉可以避免界面卡死。
g00001 19 小时 32 分钟前
FrankHB 19 小时 13 分钟前
一般开发者倒不怎么首先会关心难不难学的问题,而是开发资料是不是容易找。
于是这社区建设看起来比较捉急。
或者至少 SEO 没做好,以至于直接搜就是那么 low 的评论。
而且看上去不是一个两个的问题,怕是快人人喊打了,也是蔚为奇观……
zhihu.com/question/39393984
像这个是不是更 low 。不过你都直接上镜了啊……
v2ex.com/t/249946#r_2808385
倒是理解为什么 SEO 上弃疗了。
g00001 18 小时 58 分钟前
跨平台有很多种,其实没有真正的完全跨平台,都是部分跨平台,还得生成不同平台的执行程序,开发中还是不得不面对各种专有平台的问题,在 Electron 群里就经常看到他们在纠结一些很初级的问题。
首先在事实上 macOS + Linux 的桌面市场份额小于过气的 Win8 。跨平台的方案通常会带来不必要的负担,像 Python 开发本来是很利索的,但因为有跨平台的负担,所以写桌面界面,不如 aardio 轻快。
如果考虑事实上的 “部分跨平台” ,将一些公共的代码做成组件,用 C++ 或 C# 写都可以,或者如果用 WebView2 这种网页套壳 —— 网页部分也可以做成公共组件。
那么如果说是这种部分跨平台的话,aardio 就非常方便了,aardio 可以调用十几种编程语言以及这些语言的组件,像 C# 组件 C# 函数,或者 C,C++ 函数这些都不用写中间代码,直接可以调,更不要说调网页有多方便了。
FrankHB 18 小时 56 分钟前
不过你显然连 TortoiseHg 的官网都没找到或者仔细看,否则不会那么容易误认为“第三方”。所以我有理由怀疑你认为 GUI 至少在这里不太重要。
同时我也没妖魔化命令行。我只是说 git 的命令行尤其不好用(乃至于有用户自己包装命令行),GUI 只是新手的救星。同样是命令行,hg 就正常得多(虽然也有些问题)。
而且即便是 TortoiseHg 也不是完全覆盖了日用场景的命令,也需要命令行补充(其实 TortoiseHg 自带控制台能输入命令,但是我的系统上有其它包源安装的 hg ,我经常开终端混着用),特别是还有非官方插件。(我日常 push 就是基本在终端连续操作,因为 hg push OSDN+(hg-git) hg push GitHub 之后顺手还要 git push 到其它 git mirror ,还是全终端顺手。)
(我在其它地方有时候的确会“妖魔化”命令行,但一般是黑 shell 不够靠近“正常”的编程语言,是以 API 而非 UI 的角度来说的。作为 CLI ,黑命令行基本都是黑 cmd ,偶尔黑一下 ps1 。)
nashaofu 18 小时 56 分钟前 via Android
webview 实现方案
g00001 18 小时 48 分钟前
觉得你很有趣,
说了一下 C# 写的软件可以导出源代码,你就上升到 “人类命运共同体” 吓我一跳。
提了一下国产的 aardio ,
你这就卖力地搜索 aardio 的所谓 “黑料”,
说实话我看得莫名其妙,你到底是想表达啥意思?!
你在知乎扒了这么久,不扒到别人在问为什么同是国产语言,aardio 在网上一直是好评居多?!这就是你所谓的“人人喊打了,蔚为奇观 ……” 是你的人类命运共同体这么跟你说的?!
FrankHB 18 小时 43 分钟前 1
就跟我上面评论为什么 wx 不好(或者说不指望有什么好的未来)一样,一个主要问题是本身的结构导致可扩展困难,在二次开发集中体现的。
这导致的长期后果是继续保持市场上桌面 GUI 开发方案的碎片化,不够解决 OP 纠结的问题,还可能加剧恶化这种状况。
我找了下,Aardio 似乎就根本不提供核心实现的源代码。这就是更极端的问题了:根本不可能实现对核心进行二次开发。
如果开源,即便不提供官方支持,或许还有哪个第三方可能有兴趣移植(尽管可能跟.NET 一样过于依赖 Windows 而长期不成气候),还有资格在这个问题里作为候选;但没源码直接就是画地为牢,自绝于(专业)用户了。
即便库给源代码,但是 Aardio 又不是标准化的语言,市场占有没优势,也没什么超过 Python 之类其它流行语言独立开发的特色,有多少专业用户有兴趣贡献源代码?
所谓部分跨平台,你要 C/S 分开说还好,但看样子全是客户端的,有多少实际案例? B/S 方面,相比 cef+前端全家桶,有什么优势?
面向非专业用户的低代码工具么,看例子实际代码量也不少。只是省掉中间代码,能吸引多少用户姑且蒙在鼓里。
所以除满足需求的能力存疑外,这个定位各种方向上都很迷。
g00001 18 小时 34 分钟前
https://www.google.com/search?q=python+aardio
谁喊打了?!你那个自称 Python 用户的遥月?!
知乎上尽挖坟挖到了那些没人关注的帖子?!
500 赞的介绍 aardio 的贴子你神奇地没找到?!
https://www.zhihu.com/question/453979660/answer/1841544999
这是你说的人人喊打吗?
又开始扯 aardio 不开源吗……
aardio 官网首页的回答这个问题的这篇文章你也选择性忽视了?!
https://mp.weixin.qq.com/s/VBV5px3IPrJR40kpEk5M-w
FrankHB 18 小时 20 分钟前
不说 BS 应用,不说移动端,桌面 GUI 的整体需求应该足够明确了,市场够大,投入不小,为什么几十年来会整成这样?
“人类命运共同体”就是在黑整个业界各玩各的,谁也不服气谁,结果不说产品级方案够不够跨平台,就没整个像样的选型指导结论共识出来,搞得下游的开发者被迫站队跟着各玩各的。
原则上,你要提供一种新的方案当作选择没什么问题,但是没解决原有的问题还会有效添乱的话,那我自然不会有什么好话。
你所谓的好评,我自忖了一下,大概占据这个市场的比例不会多。当年我会按键精灵的小屁孩水平可不怎么有把握学会这一大坨,但是真会专业开发技能时,又发现这些东西完全不够看了。
而有希望成为 Aardio 目标用户的,如同上面我找到的第一个 low 的链接所说一样,可能真只有所谓的“熟手”(先不管别的方面说的是不是真的 low ),也就是退役的职业桌面开发者或者怀旧党。
具体问题很多,比如你支持 Aardio+Python ,表面降低门槛,但实际上新手连 Python 都不熟练,要同时掌握两套体系有那么容易?
另一方面就是严格的 GUI 开发本来就有隐含的门槛。
比如 GUI metaphor 和所谓控件的联系,比如事件循环,这种东西怎么明确通过 API 中的实体表现出来?讲不清楚这种道理,只是鼓吹什么样的显示效果和表面上怎么短的代码对应,是不可能简单到哪去的。(我黑 imgui 不算 GUI 库道理也类似。)
遗憾的是,我找了一圈没找到系统化描述这方面整体设计的相关内容(也可能是我没找到)。
即便是专业开发者,也得猜哪里要有等价的功能;要是能随便容忍这种缺陷,这就不只是专业 GUI 开发者,而是框架 hacker 了,自己有资源就一定能手糊出整个解决方案的那种。这种用户的忍耐是用在 Qt 这样的业界主流而不是 Aardio 这种小众方案上的。
再上纲上线一点,随便挑一个出来讲水都深得很。
比如事件循环,说白了是所有交互式程序(包括 REPL 和像样的 GUI 应用)的公共框架,作为 trampoline 是一类解释器的实现的 top-level ,也是 CESK 这样对应现代的形式语义的抽象机乃至当前物理 CPU 的顶层逻辑结构。所有这几样东西我都像模像样地自己独立实现或参与制造过,不是在工作中就是现役仍在日用的私货上,所以有第一手经验证明这不是理论废话。
基本上这些东西都有一些现实上的缺陷而让我不能满意。所以我对现状的不满其实已经收敛了许多,你觉得我有兴趣纠结区区一个局部的坑上,特意针对具体方案来形而上地黑嘛?
最后,你应该能看懂,我之前说了那么多,完全是站在鄙视区区一个桌面 GUI 都还要纠结跨平台的整个业界的专业用户立场上的。所以你觉得我是 Aardio 面向的用户群体嘛?
jones2000 18 小时 19 分钟前
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK