一个 Flutter 原生的 Wayland compositor。

Denial 始于一个信念：起源并不一定要决定用途。 Flutter 最初是为构建应用程序界面而生的。而在这里，它被赋予了 不同的生命。它完全掌控了桌面场景本身：shell、其动画效果以及 Wayland 应用程序的合成。Flutter 并不是叠加在 另一个 compositor 之上的覆盖层。它是 compositor 基础的一部分。 这就是它的架构。这也是其名字的寓意所在。  ## compositor 层的 Flutter 传统的 Flutter 桌面应用程序从现有的 compositor 获取窗口。 Denial 则更深入了一层：`deniald` 通过其原生 Embedder API 直接嵌入了 Flutter Engine，并且 Dart shell 在 compositor 进程内以 AOT 编译方式运行。 它不是 Wayland 客户端，也不需要在其下方运行另一个 compositor。 Rust 和 Flutter 有着各自独立的职责： - 基于 Smithay 构建的 Rust 负责 Wayland 协议状态、客户端缓冲区、输入 设备、焦点与捕获、输出配置、DRM/KMS 演示以及 原生资源的生命周期。 - Flutter 负责可见的桌面策略：shell 布局、窗口、系统 界面、设置、动画效果、手势，以及参与 shell 交互的区域。 Wayland 客户端缓冲区仍然是原生资源。Denial 将它们的内容作为 外部纹理导入，并将它们放置在与 shell UI 相同的 Flutter 场景中。Flutter 将该场景渲染到一个覆盖整个桌面的 GBM 图集中；每个连接的 显示器都通过 KMS 直接扫描其各自的区域，而无需对已完成的帧进行第二次 compositor 传递。 ``` Wayland clients ──> Rust / Smithay ──> external textures ──> Flutter scene input <──── native routing <──── shell hit regions <──────┘ │ Displays <────────────── DRM / KMS <────────────── shared GBM atlas ``` 原生 compositor 和 Flutter shell 作为两个独立的版本化组件进行构建。 当前的 shell 位于 `dart_shell/` 目录中，并与其 AOT 库、 assets、ICU 数据和锁定的 engine 版本作为一个运行时 bundle 一起加载。它们的 平台桥接负责承载不可变的场景状态和有边界的命令，而 不会将文件描述符、Wayland 对象、EGL 图像或 KMS 缓冲区的所有权交给 Dart。 这个 bundle 边界也是通向替代性 Flutter shell 的路径。随着 兼容性契约的稳定，兼容的用户自定义 bundle 将 能够在不替换其底层原生 compositor 的情况下，替换 Denial 的参考 shell。 ## 为什么叫 Denial **Denial** 是一个英文单词。这个名字包含了 **Denia**，并在其后加上了 最后一个字母。 这是对《鸣潮》中 Denia 的一次低调致敬。她的故事从未 直接说明她原本是什么，而这种不确定性是至关重要的。 显而易见的是，其他人将她视为一种资产：一个被挑选、 塑造并被赋予了她本身并不具备的用途的事物。她本该保持为 一个容器。然而，通过观察人类并学习与他们共同生活，她 长出了一颗心，并获得了选择自己将成为什么样子的能力。 她的故事反映了 Denial 的核心理念：事物被创造出来的初衷 并不一定要决定它未来能成为什么。 ## 项目状态 Denial 是一个正在积极开发中的公开 alpha 版本。目前的 PC 目标架构是 x86_64，并且其原生 API、Flutter bundle 契约、配置和通信 协议在 1.0 版本之前仍可能发生变化。该 compositor 已经可以作为完整的 Wayland 会话运行，支持 Xwayland、多输出显示、原生输入路由、 直接屏幕截图以及基于 portal 的屏幕共享。 ## 实时 Flutter shell 开发 可选的 `denial-ui-development` 软件包将参考 shell 转换为一个 可编辑的 Flutter 工作区。`denialctl ui setup` 会创建匹配的源码 检出并启动一个 JIT shell；在 VSCodium 中打开其 `dart_shell` 目录即可在保存时启用热重载和 Flutter Inspector，同时 Wayland 应用程序将继续保持运行。 当需要此工作流时，请单独安装它： ``` sudo pacman -S denial-ui-development denialctl ui setup ``` 受支持的编辑器连接特意设计为非暂停式。它不会授予 对 desktop isolate 的断点、暂停、单步执行或表达式求值控制。原生的 `denialctl ui restore` 命令可以恢复为打包好的 优化版 shell，即使被编辑的 Flutter 代码无法呈现可用的设置窗口也能生效。 ## 在 Arch Linux 上安装 Denial 为 `x86_64` 架构的 Arch Linux 提供了已签名的官方第一方软件包。 查阅[安装程序](install.sh)，然后运行： ``` curl -fsSL https://install.denialwm.org | sh ``` 它会验证完整的发布密钥指纹，拒绝冲突的 Pacman 配置，在需要时添加已签名的软件源，并要求 Pacman 执行正常的完整升级并安装 Denial。它会显示完整的计划， 并在使用 `sudo` 之前请求确认。 请参阅[完整安装指南](docs/packaging/arch/INSTALL.md)了解 手动设置、密钥环初始化、验证、更新和移除操作。 ## 文档 - [从 Arch 软件源安装](docs/packaging/arch/INSTALL.md) - [构建 Denial](docs/BUILDING.md) - [会话启动与锁定](docs/SESSION_STARTUP.md) - [使用 `denialctl` 控制和恢复 Denial](docs/DENIALCTL.md) - [实时 Flutter UI 开发](docs/UI_DEVELOPMENT.md) - [架构](docs/architecture.md) - [屏幕截图与屏幕共享](docs/SCREEN_CAPTURE.md) - [更新日志](CHANGELOG.md) - [路线图](ROADMAP.md) - [安全政策](SECURITY.md) - [Alpha 贡献政策](CONTRIBUTING.md) - [完整文档索引](docs/README.md) ## 通过对话创造 Denial 由其人类创作者 Doctor Logix 构思、设计、指导和测试，并与 OpenAI Codex 持续合作开发。其 初始实现是通过这种合作生成的，而不是由其 创作者手动编写的。 该项目的目的、架构、设计原则和最终的技术 决策都来自人类方面。Codex 调查了代码库，提出 解决方案，实现功能，分析失败原因，并通过 持续的对话完善系统。每个结果都针对真实硬件进行了评估， 并在未能达到预期设计或性能要求时被重新调整方向。 这是 Denial 起源的一部分，而不是隐藏在脚注中的免责声明。 创作不仅仅是敲击源代码。Denial 之所以存在，是因为一个人 决定了它应该存在什么，定义了它应该如何工作，识别出了 实现何时出了问题，并不断指导整个过程，直到想法变成了 一个正常运行的系统。 ## 许可证 Denial 的原始源代码采用 [GPL-3.0-or-later](LICENSE) 许可证。打包的第三方组件和媒体保留了 它们各自的许可证和归属声明。

标签：Flutter, Rust, Wayland, 可视化界面, 图形合成器, 桌面环境, 网络流量审计