@tw93 我是从 Android 转过来的，gradle 编译极慢，所以可能我对编译时间不是很敏感。
flutter 可以 jit 热重载，我觉得搭配 flutter_rust_bridge 可能比较合适？还有最近好像 rust 这边也出了几个 jit crate ，还没有试，准备最近试下。
如果是用 winui 的话，系统有 winui c++绑定，微软也对其做了 rust 封装。个人感觉和 c#调用其实差别不是很大，差别可能只在于语言和运行时不同，也可以实现动画的。

@1una0bserver 而且说实话，我感觉 c#写的新软件越来越少了，基本都是工控上位机领域，或者是写一些调用 Windows 平台特性的模块。
个人感觉原因可能是：配置项目不方便大多得在 vs 里配置，而且还得捆绑个体积不小的运行时；功能和性能上也和其他语言相比没有什么明显的优势，阿三还时不时整点 bug ；加上写法也和其他语言框架差异较大，所以个人一般不用。
虽然语言设计上确实很好，但是在 ai 时代，感觉没有它能大显身手的地方了。
还有由于阿三整的 win11 里一堆不同版本的.net 运行时和用 winui 重写得又卡又慢又难用的系统软件，所以我个人对于微软写的 winui 软件是比较排斥的，能用其他软件替代的都卸载掉换别的了。

c#+winui 打包以后还是太重了，个人感觉对于轻量软件并不友好，现在 ai 写 rust 很不错，c++差一点，所以我觉得底层可以大规模用 rust+cpp 写部分绑定，然后再根据平台去选择前端技术栈。
所以我对 Windows 客户端的选型是这样的：
注重美观和自定义 UI ，不怎么涉及平台特性，希望少写代码、打包方便的选 flutter/electron/tauri （如果是需要多窗口功能不建议，flutter 的现在还在测试中很多特性不支持，其他两个基本不支持）
需要较多原生能力的选 rust+cpp 混合底层+qt/c++调 winui 绑定
需要性能优化且偏 IDE/agent ，注重功能性，不怎么需要自定义绘制/动画的，或者就是单纯想要用 rust 重写一切的可以考虑 GPUI
需要高度自定义绘制（例如 shader 、webgpu ）+高性能的，建议 qt （偏工业软件）/egui （偏游戏和交互响应要求高的多媒体应用）/flutter+frb （要偏简单一点并且稳定）

是不是短号？外区的短号大多只能在他们国家的运营商才能接收。之前想用 Gemini pro 结果验证不了才知道的。

防串货，一般情况下需要同国家/同省的卡激活一次，以后就可以直接用了。

系统是支持的，但是系统日历 app 有些支持有些不支持，像你说的赛事信息很多系统直接内置了，可以到订阅里自行选择。
ics 方面，一般来说对 caldav 支持会更好些。还有 webcal 和 caldav 是两个东西，支持 webcal 的不需要改成 https ，而且一般也不支持这样。如果你的系统日历 app 没提供，到 f-droid 装个 icsx5 （ webcal ）/davx5 （ caldav ）在里面添加就行，记得给后台权限。

一眼 claude ，最近的版本特别喜欢这种宇宙风格

不要解析，通过更好的模型实现。数据清洗更重要，全部转成文本。复杂的图喂给 Gemini pro 转换，它代码绘图效果比较好。如果是一些特殊的代码没法在 markdown 里绘制的，直接根据渲染引擎自定义 parser 。

看起来不错，但是对于其他语言写的非 Web 前端框架支持怎样？比如 flutter ，Swift UI ，compose ，qt 之类的。

让 ai vibe 下，改成 cloudflare d1+worker+pages 的架构，蹭 cloudflare 的饭

看了你的代码库，很明确就是技术不行，估计人也年纪大了，学不动了。
首先，git 提交大部分都是 Update xxx 这种，完全没下过心思按内容 commit ，更别说好好写提交内容。别人完全没法贡献。这点上就是学 git 几个月的大学生都比你强吧。而且你放搜索等于没有的 gitee ，基本找不到。
其次，技术栈太旧了。从实现方式来看，感觉作者根本没有经历过大前端时代一样，除了编译链，技术栈还停留在 15 年前。
DirectUI 是 2010 年左右流行的技术，本身早就是淘汰的技术了。你要是为了兼容 XP 我还能理解，其他原因在现代用纯属自己给自己找麻烦。
XML 写 UI 都被 Google 等淘汰多久了，UI 与逻辑语言不一致，调试编译麻烦得一 p 。
引擎和 demoUI 实现也不行，我当初入门编程学的易语言，用的各种 UI 都吊打你现在的绘制效果，那还是 12 年左右。
命令式 UI 已经被响应式 UI 淘汰不知多少年了。
Mvvm 现在都比较少提了，现在热门的是 MVI 。
布局引擎现在绝大多数都是用成熟的 yoga ，无论是效果还是可维护性都更强。
sdl 现在大学生都能写了吧，而且也不算太轻量。如果要从头写的话，我很难想象除了 MCU ，即使是资源受限设备，为什么不用 Android 原生/flutter embedded/imgui/qt/rust 那些轮子，ai 写起来方便多了。
即使是说上面的框架都不允许使用，要用现代技术栈从头用各种轮子搭一个，我觉得都比直接用你这套框架写起来更快。
总之我很难想出为什么要用这套 UI 框架。

从审美和技术推断，作者的年龄可能至少也有 40+了，而且大部分都是在中小厂做 Windows/信创客户端开发，从来没有去大厂干过。并且已经有孩子并且大概率不小了。出来搞这个框架，可能是为了证明技术搞点 KPI ，可能是遭遇裁员潮失业了出来创业，或者只是单纯的爱好这方面技术。
如果不是真的爱好技术，或者真的想吃一辈子这行的饭，我建议还是转行或者转行政吧。你干了十几年，却没有积累下足够的技术，只是像拉磨的驴子那样原地转圈，连时代浪潮都没跟上，绝对卷不过年轻人的，更别说 ai 或者技术比你好的同龄人了。否则，我觉得你真的需要下苦功夫从头学习了，至少也得把各种开发规范，架构设计学学吧。

同样是 c++轻量级跨平台，看看隔壁是怎么做的: https://github.com/sudoevolve/EUI-NEO
更别说现在都是 harness + rust + GPUI 的时代了
看了一眼你的官网，更是惨不忍睹，上古 ui 风格不谈了，你连最基础的布局都做不好，在我这里显示都不正常，哥们这是 2026 年啊，不是 2006 年，你就是完全放开让 ai 自己做的主页都比你现在这好多了。。。你现在还不明白为什么没人用吗？因为真的一眼就能看出技术不行啊，甚至都不愿意下功夫打磨下。

谢谢提醒，我是接 codex ，被这玩意折磨好几天了，准备换 axonhub 。

@NekoBoss 你这个没有做其他应用的对照实验的话，我觉得很难排除是其他方面的问题。你有试过关闭其他应用的剪贴板权限之后，还能粘贴它里面吗？还有我强烈建议你按我上面的过程排查下禁止 intent/app link 后是否还会提示。
还有小米会篡改系统的 app ops 设置，然后使用它自己隐藏的 ops 权限，这点早在 MIUI 时代就是这样了，所以我几乎敢确定这不是应用本身的问题，也肯定不是 AOSP 原生的问题。似乎只有 rikka 的 app ops 应用有做这方面的处理，只不过不知道你的系统版本，app ops 停更有点久了，你的系统可能用不了。如果是这样的话，我建议你关闭 MIUI 优化再试 PMX 。
还有你说的这个，我好像在几年前就在酷安看到过类似 bug ，很难想象这么多年过去了小米还没修。如果你还在用旧版系统，那我觉得你很有必要升级下了。

先问是不是，再问为什么。op 这种很明显的先射箭后画靶的提问，都没有人复现下，就来论证什么 Android 的弊端了是吧，实在是给我看得气笑了😅
首先放我的结论，欢迎讨论：
因为这就不是只靠读剪贴板实现的，谁说 Web 往 app 传数据只能靠剪贴板的。

首先 AOSP 就没有原生的剪贴板运行时权限，各厂商所谓的空白通行证也好，剪贴板权限也好，都是在 Android 4.3+引入的 App Ops 机制上实现的，而这个和运行时权限的一个重大区别在于，这里的拒绝在实现上其实不是真的拒绝授予权限，而是通过返回空数据实现的。所以这个拒绝读取剪贴板其实就是 READ_Clipboard 权限的封装而已，虽然不能排除厂商自己魔改的实现有问题。但是我通过以下操作判断，大概率不是实现问题。
我放一下我的测试环境，Android 14 ，ColorOS ，使用 App Ops 监控和管理相关权限。
先下好客户端登录，限制其权限，关闭。在 chrome 下访问云盘页面，拉起 app ，确实成功读取到下载文件信息。
注意之后：关闭应用，按理此时已复制到剪贴板，那么我再次打开时，如果真的是读取剪贴板，应该仍然能弹出对话框，但是实际上并没有。那么就说明，可能不是读取剪贴板，或者未触发读取剪贴板的条件。尝试手动点击所有 tab ，重新手动复制剪贴板内容，均未有反应。
结合以前看到过的案例，像是 Facebook 通过 websocket 和应用通信来绕过，怀疑 websocket 。于是换了个能屏蔽本地通信的浏览器 WebLibre ，然后打开同一个网页，仍然能拉起 app 并显示弹窗，说明不是靠 websocket 本地通信，至少并不只是这个。
那么结果就显而易见了，答案就在谜面上，读取链接的方式除了剪贴板外，最简单直接的方式就在打开 app 时通过 intent/app link 传递数据！事实上，我很早就注意到了这一点，前面所有能弹出对话框的时候，基本上都是首次自动跳转和手动点击后拉起 app 的时候，而之所以这么大费周章，主要是想排除下其他可能。之后的验证就很简单了，找个能手动禁止拉起 app 的浏览器，比如 via ，禁止后打开网页，点击打开 app ，会自动复制到剪贴板。然后我们手动打开 app ，即使再次点击网页上的打开 app ，由于 intent 被阻止，即使手动切换到文件 tab ，也没有弹出保存窗口。
那么为什么 op 会认为是 bug 导致仍然能访问剪贴板呢？考虑到网盘类应用普遍在打开网页时自动复制剪贴板并跳转应用，导致注意力集中在强提示的剪贴板内容提醒，而忽略了跳转应用本身就能传递数据，加上 op 可能使用 chrome 这种不对网页唤起做拦截的浏览器，导致网页打开时的隐藏 intent 拉起被忽略，认为是自己打开的那个 app 实例。当然，我们也不能排除是 op 的 hyper OS 的垃圾代码中的漏洞导致剪贴板拦截读取无效。关于这点，我觉得都没必要先考虑漏洞问题，先随便找个开源的简单记事本应用禁止读取剪贴板，测试下能不能粘贴，再去把上面我的测试重测下，再去考虑漏洞问题也不迟。

@wniming 我是做客户端的，没写过 qt 。不过看上面的日志，有点像渲染时色彩计算的性能问题。
根据我的经验，ui 上的性能问题很多时候不一定是最直接的这个函数问题，而更多的是调用这个函数的父 widget 逻辑编写有问题。当然也可能和新内核的性能优化有关，但一般不会影响特别大。所以我偏向于是 ui 布局或者渲染逻辑出了问题，造成高频重复渲染类似的问题了。
建议你调整下背景透明度设置试试，还有拉下 konsole 最新 commit 编译下，再看看有没有这个问题。一般提 issue 还是以主线为准的，万一上游已经修复了呢。