FrankHB 最近的时间轴更新
↓挽……
34 天前
FrankHB

FrankHB

V2EX 第 34994 号会员,加入于 2013-02-28 10:06:28 +08:00
FrankHB 最近回复了
3 天前
回复了 willx12123 创建的主题 程序员 如何使用 Windows 愉快的编程?
@walpurgis WSL 不是这个原因而产生的,它的前身是意图在 Windows 上原生运行 Android app ,但因为种种原因黄了(很久之后 Win11 上 WOA 才被支持)。
反过来,用你的逻辑,也说不通为什么微软仍然花更大的力气支持 VS (不是 VSC )这种根本就是 Windows-only 的开发环境——注意是持续投入资源推动大量的功能性更新,而不仅仅是维持可用。
3 天前
回复了 willx12123 创建的主题 程序员 如何使用 Windows 愉快的编程?
可以默认用 WSL 。
嫌弃虚拟机麻烦(比如 IP 地址莫名其妙啦……),就 WSL1 ( WSL2 本质就是个 HyperV 虚拟机实例),虽然有些限制,大多数还算能用。
例外情形:
若你需要开发 Linux 内核模块本机调试之类,那当然没办法;
用 fuse 之类也可能比较麻烦;
偶尔会有些系统调用实现残缺不可用;
不要指望 systemd 之类的东西完整可用(同等层次上依赖系统实现细节的还有 nix 等);
GUI 多少比原生 Win32 麻烦且可能有无解的细节问题(例如输入法之类),性能可能也不咋地( WSLg 需要 Win11+WSL2 ),但 VcXsrv 跑个别应用基本上够用;
其它情况下,和原生 Linux 的差异是否能被容忍,取决于你自身对环境的理解(觉得不保险嫌弃麻烦那还是虚拟机了)。

如果要更原生的体验,用 MSYS2+MinGW 。
警告(相对 WSL ):原生 Win32 的构建性能会普遍降低;
小文件 I/O 性能会极其感人;
即便排除 I/O 问题,也不要指望 node.js 之类的运行时的表现不会明显变差;
同时,可能处理一些表面上容易遗漏,实际 Win32 特有的屑问题,大多是关于文件系统的:
Win32 的默认机制导致打开程序不能删除,这有时候很欠揍;
默认创建符号链接可能需要管理员权限,需要组策略变通;
Win32 不支持无视 AUX 这样的 DOS 保留文件名(但 MSYS 的工具能提供一些变通);
可能必须需要 fsutil 单独设置大小写兼容。

如果你要继续完全原生地使用 Win32 ,那么基本不会有更好的体验(以上 WSL 解决了的 Win32 问题会继续存在),并且有些问题是无解的。

@cmdOptionKana 这篇文章有些是很扯蛋的,或者至少是过时了(即便考虑原文时间无视 WSL )。

像工具方面:
很多都是 Win32 自己残废,而不是命令行;
Win32 的残废如果不是需要自己积极变通,是可以改用现有工具在 Windows 上的移植而无视的;
如 git 的不好用,大多是因为 git 自身而不是 Windows 上的实现(除了一些 I/O 性能问题)。

在如,第五点几乎全是在 FUD ,不知道是在黑 Windows 还是黑 Linux 。
你需要 hg incoming 类似的东西?
逻辑上还是少不了类似 fetch 的下载一些元数据的步骤,不过在明确只考虑这类需求(而不必然是之后紧接着会 fetch )时,确实至少会比 fetch 节约流量和带宽。
但是 2202 了,git 连 clone 的断点续传都不兹瓷,大约你也不需要指望这种东西了。
3 天前
回复了 opentrade 创建的主题 程序员 Rust 桌面程序选 Flutter 还是 Tauri?
我没法给出可靠的具体建议,不过需要指出,光是想搞清楚什么算是“前”,对 GUI 开发者来讲都经常算是不切实际的奢望。从现状看,“过时”在这个领域中不应该是需要被优先考虑的缺陷(否则很容易发现新的都是一出生就更过时的)。
cf. https://v2ex.com/t/852363#r_11667402
3 天前
回复了 zedpass 创建的主题 Linux Linux 桌面的春天要来了?
目的上……现状大致如此。如 vscode 这样的编辑器,其实用浏览器代替,也不会比 ssh 过去再用麻烦(即便编辑本地文件逻辑上比较感人)。
创业公司实际比较不好说,在 Electron 能胜任的前提下,选型主要倒不如看老板 /CTO 是不是有前端背景。如果直接有整个前端团队那么也还算是很香的(但是也别指望能做到 vscode 的程度)。

另外,我始终认为有必要把 C++/Rust 这些和所有有 GC 的方案区分,不是因为 C++之类的难度如何,而是默认情形的正确性——很大程度上,写 GUI 基本就是从头开始写 bug 。
有 GC 的语言实际上是假定资源默认推迟而没有可观察行为,这对 GUI 根本矛盾,因为 GUI 最基本的需求之一是对响应有要求(应用级的实时性),而程序内部却默认对此几乎完全放弃保证。一些像基于.NET 少数做的还能看的方案,是在框架层次上就死命优化和工具等周边生态配合的结果;相比之下,Electron 之类(浏览器实现)就无能为力或者干脆弃疗,锅都甩应用开发上了。即便是.NET 的程度,还是在鼓励默认和根本需求相违背的写法。
实际上 C++也算不上好哪去,因为 C++同样没能力显式区分描述可观察行为(无非是多了个 volatile ,没有 effect handler 之类),同样没有强制实时性的原生支持,实质上也缺少鼓励异步的写法(新手基本是写出来发现交互寄了点不动,才回去改),因此同样免不了在运行时外面套壳(指应用卡翔以后系统给出无响应界面替代而不是继续阻塞)。只是没默认 GC ,而是要求用户自己在详细设计时搞清楚所有权关系,避免默认就写出看上去顶用但实际就是一坨原生 bug 的玩意儿,已经相对算是进步了(反过来说,直接用默认 GC 的语言写 GUI ,就是明确的退步)。
照例继续多黑弃疗党的代表一下:github.com/dart-lang/language/issues/490
……看到这标题一瞬反应是 BABA 股价咋那么高了(笑哭.jpg )
4 天前
回复了 zedpass 创建的主题 Linux Linux 桌面的春天要来了?
@learningman 1. 不要看古董和野鸡教材误导浪费时间,就开发个普通的 GUI ,C++有的那些烂门槛,实际怕还不如 Qt 的非标准工具搞出来的破事多。
你倒不如说 C++开发 UI 效率整体还是低。这个尽管近些年有改善,但从没彻底解决;想跟前端比差远了。
2. Qt 的平台特定的代码,一部分是故意的(因为不是每个平台都能支持相同的功能),少部分是太旮旯,少人关心。
相比之下 Electron 更统一,但是真需要平台特定的功能,基本全部要你自己搞定。所以这个比较不公平。
不过这部分的选型问题我中立,因为 Qt 的 C++用起来算是比较恶心的,UI 以外的部分都不见得比无视 Qt ,全部自己搞定方便,所以没明显优势。
3. 那按上面我提的,当我没说。
4. 这有点强词夺理。即便是依赖 Qt 的应用,也可以要用户自己源码编译或者可以自带二进制文件,但为什么非得费力不讨好?体验明显差。
注意 Qt 的二进制文件基本上是 native 方案里最大的、跟部署个浏览器没差多少、基本上同样被鄙视的那类(特别是 Windows 上基础设施支持薄弱,装了也很难复用,到处复制 dll 算是传统艺能了),与其说兼容性,还不如说是在安装体验上拉到了几乎跟自带浏览器的应用同等低劣的水平,这点更容易让用户感知到。
就算硬盘空间不值钱,流量和用户的时间仍然经常比你想象中的更值钱。
Electron 在这里选择余地更少所以仍然更差。

@encro 大部分“桌面”应用,指的是传统上 UI 和功能集合在一个软件产品的应用。即便如此,有的(如 Office )也在往 Web 跑,回到桌面(至少在现有桌面开发体验极大改善前)不是主要趋势。
如果一个产品的服务端的重要性占比例太大并且 Web 实现够用,那么其实并不太有提供桌面客户端的需要。毕竟桌面浏览器现在整体能做到的比移动端强得多,用户习惯也普遍不一样,犯不着非得单独多给个 app 加深粘性。
既然已经部署成云服务了,顺手能写个 Web 的,干嘛非得再多此一举呢?多少有些凑 KPI 的味道了。
5 天前
回复了 rockyliang 创建的主题 程序员 关于 git 协作的一个问题
这看来是详细设计评审没做到位,或者根本就没怎么做。如果小明和小红清楚地知道对方在干啥,这种共用函数一般不会是实现了一半才发现,要么就是发现了也少到能容忍复制粘贴实现的程度。(还有种情况:A 和 B 大到设计时没法一次性做到那么细,直接扔给单人负责却又不及时同步以至于根本没法及时注意到别人做了啥,但那样是项目计划就离谱了。)
正常做法是知道共用函数后开 upstream feature branch 或者并行开 common feature branch (极端情况下嫌弃 feature 少 branch 多也可以扔 master 里,如果项目规则允许)优先实现,然后直接基于这个 branch 或者包含这个 branch 修订的某个 tag 开 A 和 B branch 。
但既然开发了一半,如果不像停工重建这个流程的话,就 cherry-pick+rebase 补救吧。是不是 squash 看约定,改动太大可能会很麻烦。
5 天前
回复了 zedpass 创建的主题 Linux Linux 桌面的春天要来了?
@encro 个别应用用 Electron 可以,带上桌面环境或者大型 GUI 应用的,Electron 基本没戏,并且不大会随着时间推移而改善——这是我先前表明的基本观点。

其实桌面跨平台开发的问题挺经的了,包括 Electron 和 Qt 在内的话题讨论过很多次。在 v2ex.com/t/841554#r_11485005 这里就有很多细节。

老实说,Qt 的问题其实非常大,纯属矮子里拔高个。关键是如果想要跨平台,就没几个选择。Qt 是现有 GUI 框架方案中功能、性能、工具、社区支持、案例资源……等方面整体均衡考虑下最完善成熟的一个。虽然设计有很多挑战忍耐力的小问题,成本也算不上很低,但是并没有像 Electron 那么显著、容易在一大类项目中一票否决的缺陷(像上面讨论的问题中 OP 直接就不接受 Electron );也没有贸然采用不那么流行的新的方案的风险。

基本上现实会考虑 Electron 的主要是两类:从现有前端项目迁移;有相对比较多的前端开发人员,但是别的人员不充裕。其它情况,Electron 很难成为首选项。特别地,想要完全解决各种没法预期的问题,和自己维护一整个浏览器的技术难度差不太多,不像其它很多方案实在不行自己魔改一下也行。相对改浏览器运行时,C++的原生框架就算需要魔改定制,都不算多困难了。

Qt 不是不能用样式,QML 这种照抄前端的方案直接就能 CSS 定制。不过我个人对那套不太感冒(开发体验也不会有 Web 成熟)。
MVVM 不是万金油,特别是有一部分典型的桌面应用不那么合适。若干年前微软发明 MVVM 的就写过一些技术文章讨论里面的缺陷,记得大致意思是比 MVC/MVP 等都更重量级,性能必须有损失(当然比起 Electron 、Flutter 之流嘛基本可以忽略),而好处基本体现不出来。不过这是相对比较细节的问题。Qt 在这个架构模式这个层次上的设计也确实不咋地(相对 WPF 等),而且要真用上 MVVM ,(就 Qt 框架设计者的 C++水平看)怕是出来的 API 只会更难看和难用。
Python 绑定用起来是一时爽,但如果要自己重现里面的技术,做框架级别的开发就蛋疼了。(最近几个月我还在头疼怎么搞出个类似 Shiboken 的东西,同时避免对 Python 的依赖。)

(其实我是有本事手糊跨平台框架,但是我没本事保证足够的人力出完善的解决方案,所以就忍了。)

其它技术,像 GTK+和 wx 这样同属 native 的,资源比 Qt 缩水多了(也许一般开发者体验到的最大的好处就仅仅是不用 Qt 恶心的 C++ moc )。而像 Flutter 之类基于动态 GC 语言的框架,大多类似 Electron ,根本上不能指望克服类似的缺陷,并且显然还没 Electron 资源丰富。
微软的一些东西做得相对中庸一点,但你没法确保啥时候微软自己怂了就跟 WPF 一样丢下转进跑路了,留下社区收拾不了的鸡肋烂摊子。再者,Windows 自己 GUI 风格带着开发体验碎片了一地,也很难让现在的桌面开发者对微软重拾信心。并且像 WinUI 这种直接扔下旧版 Windows 不管的作风(明明就算加个支持也不是很难就是不干),很多传统开发者是不买账的。
所以我不觉得这些方案有更大的发展空间能一桶浆糊。
考虑这些新的方案就没有一个打算(能不能先另说)同时解决以前的主要痛点,反倒要超额投入精力才能熟练,学到的东西复用还困难,这也太微软了。因此,在具体刚需前没什么上车的必要。
5 天前
回复了 zedpass 创建的主题 Linux Linux 桌面的春天要来了?
@learningman 牛头不对马嘴……你看看你在这里的几个回复有几个是正面回答了他人对你的说法的疑问的?
我对“企业级”什么的就没兴趣(高性能?要不是欺负的是 Electron ,啊呸……),你看看你说的是个啥?
承认 Electron 在桌面基本没生态(除非你好意思把 Web 硬是直接算成 Electron ),偶尔有个能的应用基本都是自带运行时而没有现成的系统基础设施的广泛支持,有这么难么?

所谓“从其他平台迁移”,你这个其他平台,不就是 Web ?要是有不兼容的 native 组件需要移植,也和 Electron 自己没什么关系,不管是优点还是缺点。当然你非得把一个系统上的 Electron 当作一个平台如蜜传如蜜,那当我没说。

相对地,一大票 Qt 软件直接就是原生开发好的,一样不用迁移,无非是重新构建一次,一样能做到所谓的几乎 0 成本。区别只是 Qt 故意开发不可移植的应用仍然更容易。但就这里的问题,本来用 Qt 就是为了跨平台,谁那么空哪壶不开提哪壶?所以你说的还是莫名其妙。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1249 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 19:02 · PVG 03:02 · LAX 12:02 · JFK 15:02
Developed with CodeLauncher
♥ Do have faith in what you're doing.