diff options
| -rw-r--r-- | crates/core/src/window.rs | 28 | ||||
| -rw-r--r-- | docs/TODO.md | 10 |
2 files changed, 37 insertions, 1 deletions
diff --git a/crates/core/src/window.rs b/crates/core/src/window.rs index cc841b1..a3d48a2 100644 --- a/crates/core/src/window.rs +++ b/crates/core/src/window.rs @@ -140,8 +140,18 @@ pub fn classify_menu_source(gtk_menu_path: Option<String>, is_real_gtk_applicati /// GNOME's HIG mandate, so guessing from the app id alone there would /// misclassify plenty of ordinary, well-behaved server-side-decorated apps /// that also happen to use a reverse-DNS-style id. +/// +/// `org.pwmt.*` added the same way, on the same evidence: zathura +/// (`org.pwmt.zathura`) reported live as a double titlebar - confirmed in +/// a nested compositor, screenshotted, two stacked rows with visibly +/// different button styles (srdwm's own configured style on top, zathura's +/// own girara-drawn row underneath). PWMT's own small set of tools (girara- +/// based, zathura being the only one in common use) all share the same +/// always-draws-its-own-header behaviour Firefox/Nemo needed a rule for, +/// so the namespace is as safe a bet here as GNOME's own. pub fn likely_draws_own_titlebar(app_id: &str) -> bool { - app_id.to_ascii_lowercase().starts_with("org.gnome.") + let app_id = app_id.to_ascii_lowercase(); + app_id.starts_with("org.gnome.") || app_id.starts_with("org.pwmt.") } /// State of a single managed window. This is platform-independent: backends @@ -930,6 +940,22 @@ mod button_order_tests { mod tests { use super::*; + #[test] + fn likely_draws_own_titlebar_matches_both_known_namespaces_case_insensitively() { + assert!(likely_draws_own_titlebar("org.gnome.Nautilus")); + assert!(likely_draws_own_titlebar("ORG.GNOME.TextEditor")); + assert!(likely_draws_own_titlebar("org.pwmt.zathura")); + assert!(likely_draws_own_titlebar("Org.Pwmt.Zathura")); + } + + #[test] + fn likely_draws_own_titlebar_does_not_misclassify_unrelated_reverse_dns_ids() { + assert!(!likely_draws_own_titlebar("io.github.somebody.SomeApp")); + assert!(!likely_draws_own_titlebar("org.mozilla.firefox")); + assert!(!likely_draws_own_titlebar("firefox")); + assert!(!likely_draws_own_titlebar("")); + } + fn frame() -> Rect { Rect::new(100, 100, 400, 300) } diff --git a/docs/TODO.md b/docs/TODO.md index 68b8486..71e3e59 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -1,5 +1,15 @@ # TODO / planned features - master checklist +## Zathura double-titlebar: same class of bug as Firefox/Nemo, heuristic broadened to catch it (2026-08-28) + +Reported live: "also noticed double title bars in zathura. i hope there aren't more programs experiencing this" - while checking the user's own live session for an unrelated reason, a screenshot of their real, already-open Zathura window showed two stacked title rows with two *visibly different* button styles (plain X/minus/square icons on top, filled traffic-light-style dots directly underneath) - the same tell the Firefox/Nemo double-decoration bug always had: srdwm's own server-side titlebar, with zathura's own girara-drawn header underneath it, unsuppressed. + +Reproduced deliberately in a disposable nested compositor (not the live session) to confirm before touching anything, then root-caused: zathura's app id is `org.pwmt.zathura`, which `likely_draws_own_titlebar` (`crates/core/src/window.rs`) never covered - that heuristic only matched `org.gnome.*` (GNOME's own HIG-mandated header bar), leaving zathura to fall through to `rules.lua`'s per-app list the same way Firefox and Nemo originally did, except nobody had added an entry for it yet. Fixed by broadening the heuristic to also match `org.pwmt.*`: PWMT's own small toolset (girara-based, zathura the only one in common use) shares the exact same "always draws its own header, regardless of what xdg-decoration negotiates" property GNOME's own apps do, on the same evidence (a live screenshot, not a guess) that justified `org.gnome.*` in the first place. No `rules.lua` entry needed - the heuristic now catches it automatically, same as any current or future PWMT tool. + +Verified by rebuilding and reproducing zathura in a fresh nested compositor a second time: exactly one titlebar now, no second row underneath. Full workspace build/test/clippy clean (244 core tests, +2 for the broadened heuristic's own namespace coverage). + +Also fixed, same investigation: two accidental live-session side effects from testing Firefox/Nemo's own decoration for this same report - both are single-instance apps that activate against whatever's already running regardless of a `WAYLAND_DISPLAY` override on the *new* invocation, the same gotcha already documented for Nemo earlier this session, repeated here for Firefox too. Both landed real new windows on the user's actual live desktop instead of the intended nested test instance. Owned directly rather than worked around silently; no attempt made to close either window without being asked, since guessing wrong about which window is safe to close is worse than leaving it for the user to close themselves. + ## 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. |