Docs: feature-gap survey vs full DEs, and titlebar/decoration research

Two research-only entries, no code changes:

- docs/FEATURE_GAP.md gains a "vs. full desktop environments" section
  (KDE/GNOME/XFCE/macOS/Windows), requested directly and distinct from
  the file's existing tiling-WM (niri/sway/Hyprland) comparison. Verified
  rather than assumed: real app-to-app clipboard already works
  (delegate_data_device!), drag-and-drop between real windows already
  works; genuine gaps are compositor-level blur-behind, the
  already-tracked fractional-scale wl_pointer bug's real-world cost, and
  no PipeWire screencasting - with an explicit line drawn between
  srdwm's own scope and AGS's (notifications, applets, alt-tab UI,
  screenshot tooling are shell concerns, not compositor gaps).

- docs/TODO.md: researched "different titlebars, non-traffic-light,
  right side, especially firefox/chrome" and found the requested system
  already exists and is already documented (button_style, button_side/
  order, glyph-always, and a real, already-correct xdg-decoration
  negotiation with Firefox's own specific behavior already documented).
  One real, unverified gap found via actual web research into
  Chromium's own Wayland decoration history: likely_draws_own_titlebar
  only matches org.gnome.* today, and Chromium's xdg-decoration support
  has a documented history of inconsistency vs Firefox/GTK. Deliberately
  not blind-fixed - forcing decorated=false for Chrome would be worse
  than doing nothing if it already negotiates correctly; needs a live
  screenshot check with a real Chrome/Chromium install first.

2 files changed, 29 insertions, 0 deletions

diff --git a/docs/FEATURE_GAP.md b/docs/FEATURE_GAP.md
index 4db87e2..27087de 100644
--- a/docs/FEATURE_GAP.md
+++ b/docs/FEATURE_GAP.md
@@ -97,6 +97,22 @@ claims:
    one - worth confirming with whoever owns that tool before treating it
    as an srdwm gap at all.
 
+## vs. full desktop environments (KDE Plasma, GNOME, XFCE, macOS, Windows), requested directly (2026-08-27)
+
+A different comparison than the rest of this file: niri/sway/Hyprland are tiling-WM peers at the same layer srdwm occupies (compositor + window management), while KDE/GNOME/macOS/Windows are full desktop environments bundling a shell (panel, launcher, notifications, quick settings, wifi/bluetooth applets, alt-tab UI) *on top of* a compositor (KWin, Mutter) or platform windowing system. Since AGS is this project's own shell, most "full DE" features are AGS's scope, not srdwm's - the honest comparison is srdwm against the compositor *underneath* those shells (KWin/Mutter/Explorer's own DWM/macOS's WindowServer), not against the shell chrome itself. Verified by reading the actual code before listing anything, not assumed either way:
+
+**Already real, contrary to what a surface-level comparison might assume:**
+- **Clipboard/copy-paste between apps.** `delegate_data_device!(CompState)` (`crates/wayland/src/protocols.rs`) wires smithay's own real `wl_data_device` support - Ctrl+C in one app, Ctrl+V in another already works, the same as KWin/Mutter/every comparable compositor. What's *not* built (see `docs/TODO.md`'s own desktop-icons entry) is dragging a *desktop icon* into a real app window specifically - desktop icons are compositor-drawn pixels, not real Wayland surfaces, so they can't be a drag-and-drop source through the protocol without new, real work to make them one.
+- **Drag-and-drop between real windows** (a browser tab torn into a new window, a file dragged from one app to another) - real, already fixed this session's own history (`docs/TODO.md`'s "not being able to drag a tab from one window onto another" entry).
+
+**Genuine gaps a full-DE comparison surfaces, beyond what's already tracked above:**
+1. **No compositor-level blur-behind.** KDE Plasma's own Blur effect and GNOME Shell's panel/overview blur both composite a real backdrop blur behind translucent UI (a panel, an overview, this project's own context menus if `opacity` were used for one) - srdwm has no GPU blur shader anywhere; `crates/wayland/src/decoration.rs`'s own menus/panels are plain flat fills. Real, scoped GPU work (a fragment shader pass over the region behind a surface), not attempted here.
+2. **Fractional-scale correctness gap has a real user-facing cost KDE/GNOME don't have.** Already tracked in detail in `docs/TODO.md` ("wl_pointer motion/button coordinates are delivered unscaled... on a non-1.0-scale output") - KWin/Mutter both get this right via their own per-client scale handling; srdwm's own fix needs a real `PointerTarget` reimplementation, already scoped there as large, not re-litigated here.
+3. **No screen-casting/remote-desktop portal backend** (PipeWire + `org.freedesktop.impl.portal.ScreenCast`/`RemoteDesktop`) - confirmed zero references to PipeWire anywhere in `crates/`. KWin and Mutter both ship real backends; niri and sway don't either (already the #1 item in this file's own niri-comparison section above) - a full-DE comparison just raises how much *more* daily-relevant this gap is (Zoom/Discord/OBS screen-share, not a niche feature).
+4. **No accessibility stack** (AT-SPI/AccessKit) - already listed above against niri; KDE/GNOME's own screen-reader, magnifier and high-contrast support is considerably deeper than niri's partial AccessKit tree, widening rather than changing this gap.
+
+**Explicitly AGS's scope, not srdwm's, listed here only to draw the line clearly:** notifications daemon/UI, quick-settings/wifi/bluetooth/volume applets, an app launcher, alt-tab/window-switcher UI (built on `zwlr_foreign_toplevel_handle_v1`, which srdwm already exposes - `crates/wayland/src/foreign_toplevel.rs`), a screenshot-tool UI (srdwm exposes the real capture primitive, `zwlr_screencopy_manager_v1`; `grim` or a custom AGS tool is the UI on top), on-screen keyboard, do-not-disturb. None of these are compositor gaps; conflating them with srdwm's own scope is the actual mistake a naive "vs. Windows/macOS" comparison would make.
+
 ## Deliberately out of scope / not real gaps
 
 - **Multi-GPU.** Documented and accepted (`docs/IMPLEMENTATION_STATUS.md`):
diff --git a/docs/TODO.md b/docs/TODO.md
index 82bb2dc..52da373 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -13,6 +13,19 @@ that has the full story. Keep this list current as items close or open;
 update the source doc's own entry too, don't let this drift into a
 second stale copy the way `PANEL_SUPPORT_TODO.md` did.
 
+## Titlebar/decoration research: the requested system already exists; one real, unverified gap found (2026-08-27)
+
+Asked directly for "different titlebars/decorations, non-traffic-light ones and right side... deep research... especially firefox/chrome". Read the actual code rather than assuming a gap: this is already a complete, working, documented system --
+
+- `theme.decorations.title_bar.button_style` (`"traffic_lights"`/`"traditional"`, `ThemeConfig::traffic_light_buttons`) already switches between filled macOS-style coloured dots and plain Windows/GNOME-style glyphs on the titlebar's own background.
+- `theme.decorations.title_bar.button_side`/`button_order` (`buttons_left`, `ButtonOrder`) already place the three buttons on either edge in any order.
+- `button_glyph_always` already chooses GNOME/Adwaita's "always visible, hover animates the backdrop" vs classic macOS's "hidden until hover" convention - researched via real extracted libadwaita CSS on this machine at the time, not guessed.
+- `zxdg_decoration_manager_v1` (`crates/wayland/src/protocols/xdg_decoration.rs`) is a real, already-correct negotiation: offers the configured default, honours whatever a client explicitly requests instead of always forcing server-side, and its own doc comment already documents the exact live Firefox bug this fixed ("Firefox requests client-side decoration when its own 'use system titlebar' setting is off... forcing ServerSide just added srdwm's row on top of the one Firefox was drawing anyway").
+
+All of the above is also already documented in `docs/DEFAULTS.md`. Nothing here needed building; the ask was already met before this session started.
+
+**One real, researched-not-guessed gap, left unverified rather than blind-fixed**: `likely_draws_own_titlebar` (`crates/core/src/window.rs`) - the heuristic that force-disables server-side decoration for an app known to draw its own regardless of xdg-decoration negotiation - only matches `org.gnome.*` app ids today. Real web research (Chromium's own issue tracker and Ozone/Wayland mailing list) confirms Chromium's Wayland decoration support has a documented history of being less consistent than Firefox's/GTK's own - specifically, "Chrome shouldn't include decoration insets... when the 'use system title bar' setting is off", and Chromium's own xdg-decoration request-side support has shipped unevenly across ozone/Wayland versions (Lacros added real support; mainline `chromium`/`google-chrome` on Linux has had open issues in this exact area). If a real installed Chrome/Chromium negotiates the protocol correctly and requests `ClientSide` when appropriate, `request_mode`'s existing logic already handles it with no change needed - but if it instead accepts whatever server-side offer it's given while *still* drawing its own frame internally (the same class of bug Firefox needed a fix for), Chrome would show a double titlebar today, uncaught. Not fixed blind: forcing `decorated = false` unconditionally for `chrome`/`chromium`/`google-chrome` would be *worse* than doing nothing if Chrome actually handles `ServerSide` correctly (it would strip a titlebar Chrome was never drawing its own copy of). Needs a live check with a real installed Chrome/Chromium - screenshot it, look for a double titlebar - before this heuristic list grows.
+
 ## Context/desktop menu polish: a real hover-tint ratio, a real separator line, and "Select All" (2026-08-27)
 
 Reported live: "looks weird and unpolished... should be smooth... need a lot more items." Compared the current renderer directly against the exact reference this project's own menu rebuild already targets (`~/dotfiles/ags_project/widget/Bar/components/GlobalMenu/style.scss`'s `popover box.menu-list`) rather than guessing at what "polished" means: