AvengeMedia / AvengeMedia/DankMaterialShell

Dock smart auto-hide does not react to window geometry changes on Hyprland (stays visible until a workspace switch)

Open
#3,168 2 comments 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.