srdusr
aboutsummaryrefslogtreecommitdiffstats
path: root/docs/TODO.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/TODO.md')
-rw-r--r--docs/TODO.md13
1 files changed, 13 insertions, 0 deletions
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: