AvengeMedia / AvengeMedia/DankMaterialShell
Dock smart auto-hide does not react to window geometry changes on Hyprland (stays visible until a workspace switch)
- Dominant language
- QML
- Stars
- 8.1k
- Forks
- 515
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 102
Description
## Summary
With **Intelligent auto-hide** (`dockSmartAutoHide`) on Hyprland, the dock fails to hide when a window starts overlapping the dock area due to a **pure geometry change** (moving or resizing a window). The dock then stays drawn on top of the window indefinitely and only hides after the next workspace switch, which recomputes visibility.
## Environment
- DMS **1.5.3** (Arch package `dms-shell 1.5.3-1`, CachyOS)
- Hyprland **0.56.2**, single monitor eDP-1 1920x1080 @ scale 1.5
- Dock: position bottom, `dockAutoHide: false`, `dockSmartAutoHide: true`, `dockUseOverlayLayer: true`
- Reproduced on a Lua-config Hyprland build; the event capture below and the affected code path are identical for stock Hyprland (stock also emits no events for pure geometry changes)
## Reproduction (deterministic)
1. Go to an empty workspace → dock is visible (correct, nothing overlaps).
2. Open a single floating window and place it at the top of the screen → dock stays visible (correct).
3. Move the window down into the dock area, e.g. `hyprctl dispatch movewindowpixel "exact 300 470,address:0x..."` (dragging with the mouse behaves the same).
4. **Bug:** the window now overlaps the dock zone, but the dock remains visible on top of the window — indefinitely.
5. Switch to another workspace and back → dock hides as expected, with the window at the exact same position.
I captured Hyprland's socket2 during step 3: **zero events are emitted** for the move.
## Root cause (from reading the 1.5.3 sources)
- `Modules/Dock/Dock.qml` — `shouldHideForWindows` computes the overlap from `hyprToplevel.lastIpcObject.at/size` via `CompositorService.hyprlandDockOverlapForSmartAutoHide()`.
- `Services/CompositorService.qml` (around line 184) — `Hyprland.refreshToplevels()` is only called for a fixed raw-event list (`openwindow`, `closewindow`, `movewindow`, `workspace`, `activewindow`, `changefloatingmode`, `fullscreen`, …).
- Hyprland emits **no raw event at all** for pure geometry changes (interactive move/resize of floating windows, `movewindowpixel`/`resizewindowpixel`, tiling ratio changes). So `lastIpcObject` stays stale and nothing re-triggers the visibility binding. A workspace switch both refreshes the toplevels and changes `Hyprland.focusedWorkspace`, which is why the dock "heals" exactly then.
- There is also a smaller race on `openwindow`: the visibility binding can re-evaluate before the new toplevel's IPC data (`at`/`size`) has arrived, so a freshly opened overlapping window can be missed as well.
## Suggested direction
Since Hyprland offers no geometry events, the gap probably needs a low-frequency safety net — e.g. refresh the toplevel data every 1–2 s while smart auto-hide is active and the dock is currently revealed — in addition to the existing event-driven refreshes.
I have before/during/after screenshots of steps 2/4/5 and can attach them on request.
Contributor guide
Research direction
Read Modules/Dock/Dock.qml and Services/CompositorService.qml, focusing on shouldHideForWindows, hyprlandDockOverlapForSmartAutoHide(), and Hyprland.refreshToplevels(). Reproduce a floating-window move or resize on Hyprland and confirm geometry changes refresh overlap evaluation without a workspace switch. Done means smart auto-hide responds to pure geometry changes and the openwindow timing case is covered.
Written by the indexing model from the issue text.
Assessment
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 70/100