From befafe50f1d90c7d665ef2ca15a44aee90b2954b Mon Sep 17 00:00:00 2001
From: srdusr <99972264+srdusr@users.noreply.github.com>
Date: Mon, 19 Aug 2024 21:10:00 +0200
Subject: Document that ClientInfo's geometry is the frame rect, not content

A peer session pointed out srd clients reports a decorated window's
rect 30px taller than X11 reports the client's own content window --
correct (Window.geometry is the frame rect, TITLEBAR_HEIGHT included
on top, the same convention hit-testing/rendering already use
internally), but genuinely undocumented from an external IPC
consumer's point of view. Made the frame-vs-content distinction
explicit on the field itself rather than leaving it to be reverse-
engineered from a pixel diff.
---
 crates/platform/src/ipc.rs | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/crates/platform/src/ipc.rs b/crates/platform/src/ipc.rs
index a366138..098593b 100644
--- a/crates/platform/src/ipc.rs
+++ b/crates/platform/src/ipc.rs
@@ -177,6 +177,16 @@ struct ClientInfo {
     // `ext_foreign_toplevel_list_v1` carries geometry at all, by design of
     // those protocols, so this compositor's own IPC is the only place it
     // can come from.
+    //
+    // This is `Window.geometry` verbatim: the *frame* rect, decorated
+    // window and all - for a decorated window that means `height`
+    // includes `TITLEBAR_HEIGHT` on top of the client's own content size,
+    // the same "band added on top" convention hit-testing/rendering/every
+    // other internal consumer of `Window.geometry` already uses. Not the
+    // client's own content rect, which for a decorated window sits
+    // `TITLEBAR_HEIGHT` logical pixels lower and that much shorter. A
+    // consumer treating this as on-screen window extent (e.g. an overlap/
+    // auto-hide test) wants the frame rect, which is what this is.
     x: i32,
     y: i32,
     width: u32,
-- 
cgit v1.2.3