feat: add GNOME-style intelligent dock hiding#1173
Conversation
|
please use the PR template. I will not review undisclosed AI implementations. This code duplicates a ton of dock management, observers, and logic that already exists in other area of the codebase. I recommend you review the dock auto hide manager service and rewrite your implementation following the paradigm of the rest of the app. |
|
Thanks for taking a look, I appreciate the feedback. You’re right. The current version was AI-generated and I should have been clearer about that in the PR and used the template from the start. I’m going to rework it so it fits the way DockDoor already handles Dock state and observers instead of adding a separate chunk of logic on top. I’ll go through the existing auto hide manager/service and rewrite this feature around that before I ask for another review. |
|
Thanks again for the feedback. I pushed a rewrite that should fit DockDoor a lot better than the first version. This PR is still AI-assisted, and I want to be clear about that. I used Codex/ChatGPT while working on it, but I went back through it after your comment and reworked it instead of keeping the original version. I’m also not really familiar with Swift, and the main reason I wanted to contribute this was because I think this feature would be genuinely useful in DockDoor. The main change is that the feature now lives under the existing dock auto hide service instead of using a separate manager. I also pulled the Dock/accessibility and geometry pieces into smaller helpers and removed duplicated Dock lookup logic where I could. I tested everything myself, the feature works, and the intended use cases should be covered. That said, I also understand that AI-generated code is harder to review and trust. If this can be written in a better way, I’d really appreciate it if someone more knowledgeable could make it. If you have time, I’d appreciate another look. |
|
This shouldn't require a polling timer whatsoever, and can be entirely achieved by leveraging window manipulation observers |
|
Thanks, I went back through it again and removed the polling timer. The current version is driven by the existing window manipulation observers and workspace changes instead of a repeating evaluation loop. I also cleaned up some duplicated Dock lookup paths and pushed more of the shared Dock accessibility logic into common helpers so it fits the existing structure better. I tested this version locally and the behavior is still working on my machine. If you have time, I’d appreciate another look. |
Describe your changes
This adds an optional GNOME-style intelligent Dock hiding mode.
When enabled, DockDoor now hides the native Dock when the focused window overlaps the Dock area, and shows it again when that window clears the Dock area. It also hides the Dock during drag/resize and title-bar double-click fullscreen/zoom transitions so the Dock gets out of the way before the window settles.
I reworked the original version to fit the existing DockDoor structure instead of keeping a separate manager. The logic now lives under the existing dock auto hide service, with the geometry, title-bar click handling, and shared Dock accessibility lookups split into small helpers. I also removed duplicated Dock accessibility traversal and reused shared helpers where possible.
This is opt-in and does not change default behavior unless the new setting is enabled.
Related issue number(s) and link(s)
None
Checklist before requesting a review
AI Assistance Disclosure
Did you use AI tools (ChatGPT, Claude, Copilot, Cursor, etc.) for this PR?
I used Codex/ChatGPT during development to help prototype, debug, and refactor the implementation.
I tested everything myself, the feature works, and the intended use cases should be covered.
Core Functionality Changes
This PR modifies Dock behavior when the feature is enabled.
Core changes:
Implementation notes: