Xfce 桌面环境正在经历一次意义深远的技术转型。在 X11 协议逐渐退出历史舞台、Wayland 成为主流显示服务器的背景下，Xfce 团队于 2026 年初正式宣布启动 xfwl4 项目 —— 一个从零开始构建的 Wayland compositor。这一决策不仅关乎一个组件的技术升级，更折射出整个 Xfce 生态如何在现代化与传统稳定性之间寻求平衡。
重写而非渐进修改的技术考量
项目团队最初曾尝试在现有 xfwm4 代码基础上进行修改，以支持 X11 和 Wayland 双协议并行运行。然而，这种渐进式演进路径很快被证明是不可行的。xfwm4 的架构设计深度耦合了 X11 特有的窗口管理概念，将窗口管理行为抽象为不包含 X11 特性的通用接口，在现有代码结构下几乎无法实现。更关键的是，对 xfwm4 进行大规模重构的风险极高 —— 任何引入的新缺陷都直接影响数百万 Xfce 用户的日常使用体验。
基于上述原因，团队决定采用双代码库并行开发的策略。新的 xfwl4 完全从零编写，使用 Rust 语言，实现与 xfwm4 相同的功能与行为。这种方案虽然初期投入更大，但能够确保 Wayland 实现的开发实验不会对现有的 X11 组件造成任何风险。值得注意的是，xfwl4 计划复用现有的 xfwm4 配置对话框和 xfconf 设置系统，从而降低用户的迁移成本。
Smithay 优于 wlroots 的架构优势
在选择 Wayland 支持库时，团队对 wlroots 和 Smithay 进行了深入评估。wlroots 是目前最成熟的 Wayland compositor 框架，被 sway、wayfire 等项目广泛采用；Smithay 则是完全用 Rust 编写的框架，提供更为底层的系统定制能力。xfwl4 最终选择 Smithay 作为基础，这一决策涉及多层次的技术权衡。
从功能覆盖角度而言，Smithay 支持所有官方 Wayland 协议扩展、wlroots 协议以及部分 KDE 协议，协议兼容性不逊于 wlroots。更重要的是，Smithay 没有提供像 wlroots 那样的大量高层抽象，这看似是劣势，实则赋予了开发者对图形管线、输入管线以及 Wayland 协议处理的深度定制能力。对于需要精确控制 compositor 行为的项目而言，这种底层灵活性至关重要。此外，Smithay 提供了优秀的文档，这在 Rust 生态中尤为难得。
Rust 语言本身的特性也是决策的重要考量因素。Wayland compositor 是系统底层组件，内存安全问题可能导致严重的稳定性事故。Rust 的所有权模型和借用检查机制能够从根本上消除空指针解引用、数据竞争等常见内存错误，提升 compositor 的可靠性。Brian Tarricone 本人在技术博客中坦言，相比使用 C 语言绑定 wlroots，他更倾向于直接用 Rust 编写代码。
项目范围与工程挑战
xfwl4 的目标不仅是实现 xfwm4 的功能对等，还包括若干相关的系统性改造。Wayland 体系结构要求 compositor 成为会话的根进程，这与 Xfce 当前以 xfce4-session 为核心的架构存在根本差异。因此，项目的首要任务之一是重新设计会话启动流程，确保 compositor 能够在 Wayland 环境中正确初始化并管理其他桌面组件。
对 xdg-session-management 协议的支持是另一项关键目标。该协议允许桌面环境与系统会话管理器进行标准化交互，实现用户会话的保存、恢复等高级功能。此外，XWayland 兼容性层的支持也被纳入路线图 —— 尽管 X11 应用终将逐步淘汰，但在过渡期内保留对现有应用程序的兼容仍然必要。Xfce 团队计划在 2026 年中旬发布首个开发版本，届时社区将能够评估项目的实际进展。
项目团队在 GitLab 上公开了 Issue 跟踪和开发中源码仓库，技术细节对所有参与者可见。这种透明的开发模式有助于社区贡献者理解架构决策并参与测试反馈。对于正在考虑类似迁移的桌面环境项目而言，xfwl4 的实践经验具有重要的参考价值。
参考资料
- Xfce 官方博客：《Xfwl4 - The roadmap for a Xfce Wayland Compositor》
- Smithay 官方文档与 GitHub 仓库