传统Wayland合成器将合成器与窗口管理器合二为一，增加了开发负担。River 0.4.0创新性地将窗口管理器分离为独立程序，通过river-window-management-v1协议赋予窗口管理器完整控制权，同时保持River底层渲染性能。这种解耦设计为Wayland生态带来了更灵活的架构选择。

标题：Wayland合成器与窗口管理器的分离

传统Wayland合成器采用单一架构，将合成器与窗口管理器整合为一个程序。这种设计存在弊端，要求窗口管理器开发者必须实现整个Wayland合成器。

非单一架构的Wayland合成器river在0.4.0版本中突破传统，将窗口管理器拆分为独立程序。目前已有多个窗口管理器与river兼容。

稳定的river-window-management-v1协议赋予窗口管理器对窗口位置、快捷键等所有窗口管理策略的完全控制权，而river本身则负责帧完美渲染、高性能表现和底层基础功能。

架构演进

传统Wayland架构将三个角色合并： 1. 显示服务器：处理内核输入事件与显示缓冲 2. 合成器：合成可视窗口缓冲 3. 窗口管理器：窗口排列与用户交互

相比X11架构中显示服务器作为中间层导致的延迟问题，Wayland通过合并显示服务器与合成器解决了这一弊端。但窗口管理器的整合并非技术必需，更多是历史选择。

协议设计原则

新协议必须确保： - 不因每帧或每次输入事件产生往返延迟 - 保持"帧完美"特性（窗口状态变更时无视觉瑕疵） - 通过状态机设计分离管理状态与渲染状态

开发者优势

分离架构显著降低开发门槛： - 窗口管理器崩溃不会导致会话丢失 - 支持使用高级语言开发（如垃圾回收语言） - 调试难度大幅降低 - 已有15款窗口管理器涌现

当前限制

暂不支持： - VR等非传统2D桌面场景 - 复杂视觉效果（如弹性窗口） - 开发者可通过提交issue提出需求

未来发展

1.0.0版本前将重点优化窗口管理器启动/切换体验。用户可通过问题追踪系统了解规划路线。

项目支持

作者呼吁通过liberapay等平台进行捐赠以维持项目发展。

示例展示

包括Canoe、reka等特色窗口管理器实机截图。

（注：原文中技术细节图表及部分推广性内容已精简，保留核心架构解析与开发者价值主张）

以下是评论内容的总结：

1. Wayland与X11架构差异

• 主要观点：Wayland依赖内核功能，相比X11更简化，但仍存在挑战。
• 论据：
  • "Wayland compositors all rely on lots of kernel facilities... X is basically it's own kernel"（评论1）
  • "the kernel is helping so much... it's a much simpler world"（评论1）

2. 窗口管理器与合成器的分离

• 支持观点：分离设计降低开发门槛，更具灵活性。
  • "Separating the compositor and window manager feels like one of those ideas that seems obvious"（评论6）
  • "this is the first time Wayland feels like it's not a waste of time"（评论9）
• 质疑观点：Wayland默认设计导致用户功能损失。
  • "Wayland can't just substitute out pluggable WMs without changing... infrastructure"（评论2）
  • "If Wayland doesn't get this solved then I'll just use X11 forever"（评论3）

3. 用户实际体验对比

• Wayland优势案例：
  • "using a fully vibe-coded, personal River window manager... works just how I want"（评论4）
• X11优势观点：
  • "X11 has warts but I can make it do basically anything I want"（评论5）
  • "remote access... just works in X11"（评论9）

4. 安全性与设计争议

• 安全模型支持：
  • "It's much more secure that way and it works perfectly fine"（评论11）
• 历史设计疑问：
  • "Wasn't one of Wayland's key design features combining the window manager and compositor?"（评论10）

5. 开发者体验

• 文档不足问题：
  • "I don't recall ever viewing an easy-to-follow lesson... explained the various components"（评论7）

总结呈现了技术架构讨论（45%）、用户体验对比（30%）、安全性争议（15%）和开发体验（10%）四个核心维度，引用覆盖了正反双方代表性观点。