北京
距离boringcactus发布《A 2025 Survey of Rust GUI Libraries》已经过去一年多。那篇博客相当有趣，有趣到让我想亲自下场试试。这次，我逐一测试了Are We GUI Yet?网站上列出的每个库。
测试任务：二维码生成器
我选择的任务是做一个二维码生成器：界面有一个文本框，输入文字后，Rust后端根据文本计算出对应的二维码，并显示在文本框下方。
这个任务能覆盖GUI框架需要面对的很多方面。比如，文本框涉及IME输入法支持，从后端显示图片则考验框架与现有Rust生态的兼容性。此外，这个任务也是我今年第一次用Rust开发GUI程序时遇到的一个真实案例的简化版。
除了基本功能完整性，我还会给出相当主观的易用性评分，涵盖状态管理、样式、初始项目搭建的复杂度，以及编辑器体验。
为了获得真实感受，我会尽可能手写每个任务。当然，到了2026年，一个重大区别是编码代理的实际应用。如果我在调查中遇到一个自己搞不清正确用法的框架，但编码代理能替我写出正确的代码，那我仍然会给这个框架一定的易用性加分。
我使用的是macOS，所以本次调查基于macOS平台。对于某些特定于Windows的框架，我也会尝试在Windows虚拟机中运行。
结论和汇总表格在文章末尾。
Azul：出师不利
打开Azul的主页，迎面而来的是一个相当有野心的页面，介绍Azlin Workspace、Azlin UI Toolkit和Azlin OS。虽然Azlin Workspace基本上是一堆"即将推出"的通知，我也不确定Azlin和Azul有什么关系，但我还是设法越过了主页，在GitHub上找到了正确的用户文档。
Azul似乎刚刚发布了0.2.0版本。根据文档，我可以通过Homebrew安装它的运行时库。然后，由于Azul没有发布在crates.io上，我不得不克隆它的Git仓库并运行它来生成Rust API绑定。
第一个问题马上就来了：rust-analyzer无法识别Azul生成的Rust代码。代码能编译也能运行，但相关类型的所有编辑器提示都消失了。
好吧，这不算什么大问题，至少还有cargo doc可用。这就像回到了没有LSP（语言服务器协议）的编程时代。
花了10分钟翻cargo文档，反复调用编译器，我终于把文本框塞进了它原来的示例里。但接下来，无论我怎么做，都无法让输入到框里的文字真正显示出来。于是我请Codex帮我调试这个问题，结果发现Azul显然无法……
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
