- 主题:自 Petzold 以来，微软再也没有过连贯的 GUI 策略
好像除了我们这些老人家。
也没人在乎这些事了吧。
win32GUI 编程真的还在人干吗？
【 在 Jacqueline 的大作中提到: 】
: Jeffrey Snover, glm5翻译
: [upload=1][/upload]
--
修改:hgoldfish FROM 222.79.179.*
FROM 222.79.179.*
话说，现在 win/linux 下，java swt 对比之下好像也不差。
以前入门难度比较高的问题，现在有 AI 也方便很多。
swing 自绘中文不好看的问题不知道解决了没有。
以前觉得 idea, netbean 笨重。如今跟 vscode 这些 js 的比起来简直眉清目秀。
【 在 z16166 的大作中提到: 】
: 全都可以笼统归结为大公司病呗。但apple的软件架构的演进好像没这么夸张。
: 跟Charles Petzold没啥关系，他只是个布道者吧，win32 api又不是他拍板设计的
--
修改:hgoldfish FROM 222.79.179.*
FROM 222.79.179.*
话说。你们这些 pascal/delphi 拥趸，应该弄几个杀手级应用。再不济把 fterm 维护起来。多一些此类开源项目，可以多吸引一些人来使用 pascal/delphi.
单纯说教没啥用。
历史上，被广泛使用的框架与语言都是这样子推动起来的。
【 在 ooolinux 的大作中提到: 】
: RAD Studio（Delphi、C++Builder）、Lazarus可以有
: [upload=1][/upload]
--
FROM 222.79.179.*
可笑的是，巨硬已经烂成这样子了。
还没有其它厂商的操作系统能够打败巨硬。
【 在 iwantfly 的大作中提到: 】
: 我的意思是，微软这些框架， 主推c#/directx本身并没有问题，但是它埋下了排斥其他技术和标准的坑， 现在都成了它的缺陷
: 这些框架是可以使用c/c++的，它的封闭本质上是在于它完全闭源和封闭了渲染管线, 即使集成c++也无法进行原生/外部渲染
: 它在商业上失败了，主要在于封闭和垄断，商业失败又引发一些列技术迭代
: ...................
--
FROM 222.79.179.*
windows 系统本身也是用的纯的 win32api. 这就是文章所说的，巨硬内部各有自己的小算盘，每个部门之间相互不支持。
直到 win11, 奇葩 windows 开始菜单被换成了 reactjs native 写的一套框架。所以 win11 点开始菜单会觉得卡卡的。
【 在 adoal 的大作中提到: 】
: 说起来，神奇的是，Office的UI是自己单独搞了一套私有的框架，
: 没使用上述的微软任何一个框架……大概这也是混乱得以持续的
: 一个重要原因吧。
: ...................
--
修改:hgoldfish FROM 222.79.179.*
FROM 222.79.179.*
有吗？
我的 cursor 经常爆卡啊。
明显弱于 eclipse 和 pycharm.
我经常同时开 qtcreator, pycharm, cursor 三个 IDE，感受非常明显。
【 在 adamhj 的大作中提到: 】
: 我不觉得，vsc这些js方案的虽然也很大，但是速度明显快，渲染效果也好很多
--
FROM 222.79.179.*
巨硬应该不会这么疯吧。
以前 Windows 的图形子系统就是在内核内核的，到了 win7 就移出来了。
巨硬的 refs 到现在还没法作为 c 盘主系统使用。好几年没有新特性了。
Windows 内核估计就这么慢慢烂下去。
【 在 tgfbeta 的大作中提到: 】
: 估计十年之内，微软就会把DOM放进内核或者某个子系统，然后大家就写native web app了吧
--
修改:hgoldfish FROM 222.79.178.*
FROM 222.79.178.*
按这篇文章的背景谈到的，win11 的一些桌面组件，像那个 copilot 和菜单就是跑在 webview2 上面的。
所以才会有卡顿的感觉。
不过 shell 不算。以前 win98 的桌面也是个 IE 浏览器核心。叫做活动桌面，不知道你们还记不记得。当年 win98 的的第一优化技巧就是关闭活动桌面。
就怕有人往内核里面引脚本语言。像 netbsd 已经往它们的内核里面引 lua 了。linux/freebsd 是 eBPF 这种编译型语言还好一点。
【 在 adamhj 的大作中提到: 】
: win11已经自带webview2了吧
--
修改:hgoldfish FROM 222.79.178.*
FROM 222.79.178.*
这显然不可能啊。
每个进程都有自己的资源空间。
即使这个 webview2 放到内核里面，也没法真正实现。
因为现有的 dom 模型不支持这种元素在不同进程的抽象。
【 在 tgfbeta 的大作中提到: 】
: 如果是每个widget都想create一个webview2那当然是卡的
: 如果微软把webview2作为native的GUI service provider
: 大家只是在DOM上创建一个element，不就好了？
: ...................
--
FROM 222.79.178.*