普通窗口为何需要获取自身位置

Wayland 宣称设计初衷即是窗口位置避免暴露给客户端，以便管理。其实，纵览 weston 源码后，我反而找不到在 desktop-shell 坚持这个初衷有什么用（别告诉我多端输出之类，那是 wl_surface 的活），当然其他应用场景另当别论。

传统的多窗口管理，窗口位置由客户端决定，服务端管理交互并将变动告知客户端。

后来，因为很多程序并未妥善处理自身初始位置，发生多次重叠甚至强行获取焦点等时有发生；也因此，改进的窗口管理器对普通窗口（即非弹出菜单等）的位置及聚焦请求进行适当处理（即由管理器决定如何响应，早期 twm 或 wmaker 等甚至由用户指定），但变动与否依然告知客户端。

再甚者，还有坚持不响应客户端位置与聚焦请求，而按固定布局（或一定规则）进行管理的多窗口管理器（比如 dwm 或 i3 等等），但客户端依然能知悉普通窗口位置。

而现在，居然在 Wayland 的 xdg-shell 协议中，只有 set-geometry，而无 get-geometry，真是见鬼了。。。其实 weston 中要加上此项功能，简单之极，不过其依然保持初衷。我想这也许是现今 GTK 等的 Wayland 实现不得不妥协于让窗口位置永远保持 (0,0) 的原因吧（gtk-shell 未深究，不敢妄自揣测）。

遑论是何初衷，对于普通窗口而言，知悉自身位置，能充分决定各种弹出窗口（或子窗口）的行为特点，使其更为合理化；比如超出或接近屏幕边缘时的滚动、简略化、偏位处理等等，更不说多程序协同（输入、监测等等）了。结果 Wayland 现在还整出来个 input_panel 协议，真令人不解。

见鬼用鬼招

想了一下，不去动 Wayland 协议，也不去为它画蛇添足，要破这个局，有个鬼招：每个程序都拥有一个 fullscreen 的 xdg-shell，自己负责自身合成及区域处理（相当于自身即是 compositor），不过透明区域输入事件如何与 Wayland 协作将又是一个可能无法突破的坎，毕竟它还是 so simple 。

另一鬼招，既然 set-geometry 可用，若能 grab_pointer，移动放缩自实现，忽略所有相关事件（configure等等）。