diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/TODO.md | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/docs/TODO.md b/docs/TODO.md index 691e63b..68b8486 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -1,5 +1,23 @@ # TODO / planned features - master checklist +## A real regression in the shadow-tint fix: dynamic-mode windows lost their shadow entirely (2026-08-28) + +Reported live: "why is super+s toggling tint/shadow of window. it should toggle tiling/floating." Caught immediately, not defended: the tiled-shadow-tint fix earlier today (`b7f3eff`) gated the shadow on `Window::floating` alone - `if shadows_enabled && w.floating && !w.maximized && !w.fullscreen`. `arrange_workspace` only ever reads `floating` under the `"tiling"` layout; every window on this project's own default `"dynamic"` layout starts, and stays, `floating: false` unless something explicitly flips it. That gate therefore read `floating: false` as "this window is tiled, no shadow" regardless of which layout was actually running - so every window under dynamic/floating mode (this session's own stated daily-driver preference) silently lost its shadow outright, recoverable only by toggling `Super+S` (`srd.window.toggle_floating()`), which then looked like that key toggles a "tint" rather than floating - floating itself does nothing visible under a layout that never tiles anyone, so the shadow reappearing was the *only* thing Super+S visibly did. + +Fixed by checking the window's own workspace layout first: `currently_tiled = workspace.layout == "tiling" && !w.floating`, shadow shown whenever `!currently_tiled`. `Window::floating` only ever means "opted out of tiling" *within* a workspace that tiles at all; a dynamic-workspace window is never "tiled" in the first place; regardless of its own `floating` flag, so it now always keeps its shadow, matching every other floating desktop window on any real OS. `DecorationSignature`'s own `floating: bool` field (added alongside the original fix, to invalidate the decoration cache when floating changes) is now `currently_tiled: bool` instead, computed from the workspace's layout too - a `Super+Shift+t`/`s` layout switch changes this for every window on that workspace without touching any of their own `floating` fields, and the old field would have kept serving a stale cached shadow state across exactly that switch. + +Separately and directly: "i never ever asked you to tint windows ever and that has caused me a lot of problems in trying to get color accuracy... shadowed borders like how other systems do yes. tinting no." `general.shadows` was never actually asked for - it defaults `true` in the engine itself and had been on the whole time with no line in the user's own `~/.config/srd/init.lua` to show it, confirmed by grep. Set to `false` there now, with the reasoning written into the config itself: a drop shadow is mechanically a translucent dark gradient blended over whatever's behind the window, unavoidably colour-affecting near its own edge regardless of how correctly it renders otherwise - exactly wrong for colour-accuracy work. The window's own solid `border_color`/`border_width` is untouched by this setting and unaffected by any of today's shadow work, still giving every window a fully opaque, crisp edge. + +Full workspace build/test/clippy clean. + +## Context menu text was silently cut off past a fixed 170px width (2026-08-28) + +Reported live: "some of the text goes out of view in the context menu" - clarifying an earlier misdiagnosis (the previous entry below wrongly read this complaint as being about the "Floating" toggle's own inapplicability, which was real but not what was meant). Root cause: both `ContextMenu` (titlebar) and `DesktopMenu` (desktop icons) used a fixed `MENU_WIDTH = 170` regardless of their own actual longest label - comfortably fit short ones ("Minimize", "Close") but not longer ones added since ("Button Style: Traffic Lights", "Open in File Manager", a user-configurable workspace name), which `render_context_menu`'s own overflow guard (`if pen_x as usize >= width { break; }`) just silently truncated mid-character with no ellipsis or indication anything was cut. + +`srdwm_core::context_menu` has no font of its own to measure real glyph widths against (it's backend-agnostic by design), so the fix lives on the Wayland side, where one already exists: a new `decoration::measure_text_width` (real per-glyph advance-width summation, the same measurement `render_header_box`'s `draw_centered` already did inline for the lock screen) lets `open_context_menu`/`build_desktop_menu_buffer` widen `menu.width` to whichever real label is actually widest, before rendering - only ever grows the width past the built-in minimum, never shrinks it. Applied to both menus, since both had the identical fixed-width bug, not just the titlebar one that was reported. + +Full workspace build/test/clippy clean. + ## Titlebar right-click menu redesigned: real separators/headers, an inapplicable item hidden, live customization added (2026-08-28) Reported live: "looks very ugly currently and some of it doesn't make sense." Both were real, found by reading `srdwm_core::context_menu` and `decoration::render_context_menu` directly rather than guessing at what "ugly" meant. |