Docs: global menu research - confirmed current, no code gap found

Real web research (KDE's own source tree, current as of Plasma
6.6.5/2026): com.canonical.AppMenu.Registrar + dbusmenu is still the
current, unreplaced global-menu mechanism in KDE Plasma 6, and generic
Qt apps still export via the same QGenericUnixTheme path since Qt 5.7 --
exactly what srdwm's own appmenu_registrar.rs/appmenu.rs already
implement. No newer protocol to catch up to, no code gap found. srdwm's
own scope (discovery/registration) is correctly split from AGS's
(rendering) - see the FEATURE_GAP.md entry from the previous commit.

1 files changed, 6 insertions, 0 deletions

diff --git a/docs/TODO.md b/docs/TODO.md
index 52da373..959df49 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -26,6 +26,12 @@ All of the above is also already documented in `docs/DEFAULTS.md`. Nothing here
 
 **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.
 
+## Global menu research: confirmed current/correct, no newer protocol to catch up to (2026-08-27)
+
+Asked directly to research the global menu further. Real web research (KDE's own source tree at `lxr.kde.org`, current as of Plasma 6.6.5/2026) confirms `com.canonical.AppMenu.Registrar` + dbusmenu - what `crates/platform/src/appmenu_registrar.rs`/`crates/wayland/src/appmenu.rs` already implement - is still the current, unreplaced mechanism in KDE Plasma 6, not a legacy protocol superseded by something newer. Also confirmed: generic (non-Plasma) Qt apps export via `QGenericUnixTheme`'s own registrar-based path since Qt 5.7, matching exactly the real-world case (a Qt app running under srdwm, not under Plasma itself) srdwm's implementation targets. No code gap found - srdwm's own scope here (discovery/registration: which app owns which menu, over D-Bus and the X11/gtk-shell property paths) is already complete and correctly split from AGS's own scope (rendering the discovered menu's real content, a `Gtk.PopoverMenuBar` built from the app's `GMenuModel`) - see `docs/FEATURE_GAP.md`'s own AGS/srdwm scope line.
+
+One real, already-tracked loose end this touches: `docs/TODO.md`'s own XWayland cold-start crash-loop entry above notes the registrar previously never got a chance to claim ownership from AGS because XWayland crash-looped before `AppmenuRegistrarState::new()` could ever run - that fix is built but "not yet confirmed live" (needs a restart). Global menu's own correctness is otherwise not in question; that restart-confirmation is the only remaining unknown.
+
 ## 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: