我正在编写一个 Wayland 客户端，仅使用 Wayland C 库 (wayland-client.h)。我希望尽可能少地添加用于移动、调整大小、最小化和关闭窗口的窗口装饰。
我看到的选项是：a）请求合成器在我的 Wayland 表面周围绘制窗口装饰（服务器端装饰），或者 b）使用一个小型库或代码在客户端自己绘制装饰（客户端装饰） )。
有哪些方法可以实现这两种选择？例如。对于简单的hello_wayland 示例，我如何请求服务器端装饰 (a) 或如何在客户端 (b) 中绘制窗口装饰？对于后一种选择，我正在寻找类似 Rust 库 https://github.com/Smithay/wayland-window 的东西，但适用于 C/C++。
编辑： 对于客户端装饰选项（b）我找到了专用的装饰库libdecoration。
【问题讨论】：
更新： 如果您不阅读 cmets，只想强调原始答案中概述的协议已被接受为不稳定的。 https://github.com/wayland-project/wayland-protocols/commit/76d1ae8c65739eff3434ef219c58a913ad34e988
原文： 目前，在 Wayland 上没有标准/稳定的方式来进行服务器端装饰。协议本身并不允许服务器端装饰，但它似乎并没有优先考虑它。 （尽管如此，抱怨是没有实际意义的，因为无论如何都要在 xdg 命名空间协议下为桌面重新定义 shell 协议。）
KDE 显然受到了影响，尤其是因为 Plasma Shell 使用服务器端装饰来保持一致的主题。 KDE 人员为其实现提供了一个协议扩展，简称为“服务器装饰”KWayland server-decorations。你可以测试这个接口，如果它存在就使用它。
更长期的解决方案还没有落地。这是开发 Wayland 协议的一群人（可能是 XDG 协议）必须达成一致的。有人尝试将其以 xdg-toplevel-decoration 的名称加入 xdg 命名空间的 Wayland 协议中。该补丁最终被标记为已被取代。修补此协议的最新尝试仍处于提案状态 - xdg-decoration。
如果没有服务器端的装饰，您将不得不绘制自己的装饰（以及处理关键事件以使窗口正常工作）。我觉得 a 协议会在某个时候出现 - 缺少一个协议需要大量的扩展协议和代码异味检查每个协议。尽管如此，我希望目前缺乏行动是因为新协议的提案阶段本质上是挑剔的。一个协议在发布为稳定后很难更改，因此可能需要一段时间才能看到它甚至进入不稳定状态。
我的建议是继续表示支持这种更改，但要保持耐心，不要认为它会很快到来（我们甚至没有拥有不稳定的协议状态）。同时，如果您真的想完成工作，请检查 KDE 的 server-decorations 协议扩展，如果可用，请使用它。 并且不要假设它会可用。
【讨论】：