diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/TODO.md | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/docs/TODO.md b/docs/TODO.md index 959df49..d06cc54 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -26,6 +26,18 @@ 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. +## Codebase modularization: split the one genuinely monolithic file (2026-08-27) + +Asked directly to modularize the codebase. Surveyed first rather than guessing where: at ~38k lines across the workspace, the codebase is already organized the way `crates/core/src/manager/` and `crates/wayland/src/{state,udev,decoration}/` already show (one topic per file, a slim `mod.rs`), and most individual files are a few hundred lines. `crates/platform/src/ipc.rs` was the one real outlier - 1894 lines, a single flat file holding the socket/connection lifecycle, every response/event payload type, both dispatch match statements, and its own test suite all at once, unlike every other multi-concern area of this codebase. + +Split into `crates/platform/src/ipc/` by concern, matching the established pattern exactly: +- `mod.rs` - `IpcServer` itself (socket lifecycle, the subscribe-broadcast poll loop). What callers outside this module see (`pub use ipc::IpcServer` in `lib.rs`) is completely unchanged. +- `types.rs` - every response/event payload struct plus the snapshot functions that build them from `WindowManager`. +- `dispatch.rs` - `handle_request` (every query/dispatch `cmd`) and `handle_set` (the `"set"` cmd's own sub-dispatch). +- `tests.rs` - the existing test suite, moved verbatim. + +A pure reorganization, not a rewrite: extracted with exact line-range copies (verified against the original file via `git show HEAD:...`, not retyped) rather than reproduced from memory, specifically to rule out a transcription bug in a file this central. Confirmed zero behavior change the only way that actually proves it: build/test/clippy all clean before and after, with the *exact same* test count (29 in `crates/platform`) both times, not just "still green". + ## 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. |