Enhance dock visibility management with global polling and edge detection

[massimiliano-dalcero]

Description

This PR resolves the ongoing issues where the dock fails to reliably unhide when the pointer touches the screen edge. The primary symptoms resolved are:

1. The dock refusing to unhide if GapSize > 0 is configured.
2. The dock unhiding only when the pointer is strictly enclosed within the visual bounds (width) of the dock.
3. Completely broken edge unhiding under modern XWayland setups, due to strictly clipped X11 PointerBarrier event handlers.

Key Changes

• Universal Edge Detection: Bypasses failing external /XInput edge barrier hooks with a highly lightweight global coordinate poll. This natively tracks and detects pointer edge-collisions across the entire monitor geometry, guaranteeing the unhide even if the graphical module fails to map correctly to the absolute boundaries.
• Infinite Lateral Slide: Modified the internal HideManager tracking intersections. While visibly hovering, horizontal bounds are conceptually evaluated as infinite; resolving the annoyance of the dock closing instantly if a user carelessly slides outside its physical components horizontally.
• Native Gap Parsing: Coordinate polling mathematics natively absorb the GapSize, bridging the empty event-space between the physical screen edge and the vertically-restricted graphical GTK frame.
• Exposed monitor_num inside PositionManager.vala as a public getter to accurately parse scale mapping against the user's targeted multi-monitor configuration.

[zquestz]

Will look at this soon.

[massimiliano-dalcero]

Here’s a cleaner, more polished version in English for your GitHub PR comment:

---

Hi @zquestz 🙂

Just to provide a bit more context:

The code I proposed was intended to improve usability by introducing the following behavior:

• The auto-hide dock is revealed whenever the mouse reaches the screen edge where the dock is positioned, without requiring the cursor to enter the dock’s actual width (similar to macOS behavior).

• It also works correctly when a gap greater than 0 is configured.

Thanks again for your interest!
Max

P.S.
I hope this is of interest, I’ve set this modified dock behavior as the default in the Drift Linux forensic distribution (driftlinux.org).
The screenshots on the website are not yet updated, but the feature is already included in the ISOs.

[zquestz]

So, finally got a chance to look at this a bit more closely.

This isn't quite ready to merge as is, but overall I do like the direction. When I added GapSize, I piggy packed on the X barrier logic, but this doesn't work with all input devices, and apparently doesn't work with Xwayland.

The correct fix is to actually remove the reliance on X barriers, and only use X barriers when pressure reveal is used.

That means the existing GapSize logic needs to be refactored, and cleaned up so that Plank Reloaded always uses the polling detection when GapSize is set.

Also, I am not a fan of extending the hit area to 3 pixels... This leads to accidental unhides on my system. Also, I think the change to unhide outside the dock width should be a setting, as this regresses behavior when someone has multiple docks... They technically could have TWO docks on one side, and then both would appear when they go to the screen edge.

[zquestz]

Thanks for the PR and the work you put into this! I've gone ahead and implemented an alternative approach in dda4d925a that addresses the core GapSize unhide issue while keeping things scoped.

Here's what I landed on:

• Edge pointer polling (100ms) runs only when GapSize > 0, the dock is hidden, and HideMode != NONE — zero overhead otherwise
• Barriers are now only for PressureReveal — fully decoupled from GapSize
• Detection is scoped to the visible dock bounds — no full-edge triggering, so multiple docks on the same edge won't conflict
• Dock reveals without magnification — icons appear at normal size via a pending_reveal mechanism, magnification only starts when the cursor actually enters the dock window
• Reveal timeout adapts to theme animation speed so slow animations aren't cut short

I appreciate you surfacing this issue — the barrier-based approach for GapSize was definitely fragile. The polling approach you proposed was the right direction, I just wanted to keep the detection area tight and avoid changing the existing event-driven hover system.

[massimiliano-dalcero]

Hi @zquestz,

Thanks for taking the time to look into this and for implementing an alternative fix! I really appreciate the clean approach you took to solve the GapSize issue without breaking the existing event-driven system.

Unfortunately, for my specific use case, having the unhide trigger along the entire screen edge was highly usefull. From a usability standpoint, "guessing" or aiming for the exact position of the dock to reveal it isn't always easy or intuitive, especially on larger screens or during fast workflow moments.

Would you be open to adding a configuration toggle (e.g., "Full edge detection" or something similar) that is disabled by default?

This way, the standard behavior remains perfectly intact for users with multiple docks or specific setups, but it would give users who prefer a macOS-style full-edge reveal the autonomy to enable it if they want to.

Let me know what you think. Thanks again for your great work and for keeping this project alive!

[zquestz]

This is a solid idea. Do you need it to be full screen for all gapsize values? It would be easy with the new polling code, but the event trigger is on a 1px edge of the dock window itself and could be trickier to implement.

[massimiliano-dalcero]

Hi @zquestz,

Yes, for my use case I would prefer full-edge detection for all GapSize values, as long as it is behind a dedicated option and disabled by default.

What I’m looking for is essentially an optional macOS-style behavior, where the dock can be revealed by touching the whole screen edge rather than only the exact dock bounds.

I completely understand that implementing this through the old 1px event-triggered path may be trickier. If it is easier and cleaner to support this only through the new polling-based logic, that would be perfectly fine for me as well.

So, from my side:

• default behavior unchanged
• optional toggle for full-edge reveal
• works across all GapSize values

Thanks again for considering it.