[CappyT]

Summary

This fixes the issue where, with intelligent autohide enabled and the dock centered at the bottom, the dock does not dodge windows tiled to the right half of the screen, while windows tiled to the left half work fine.

Closes #2413

Root cause

_updateStaticBox() computes the intellihide target box from this.x + this._slider.x. The slide container is centered inside the dock actor with ActorAlign.CENTER, so its final x offset is assigned by the layout machinery during allocation. Layout driven allocation changes do not emit notify::x (that signal is only emitted for explicit position changes), and the recomputation is currently only wired to notify::x / notify::y on the slider and to notify::allocation on the dash container. In practice the last recomputation can run while the slider still sits at x = 0, and the target box then stays anchored to the left edge of the dock actor.

Measured on an affected setup (GNOME Shell 50.3, extension v105, 3440x1440, bottom centered dock) by inspecting the running shell:

real dock box on stage:  x1 = 972, x2 = 2467
intellihide target box:  x1 = 172, x2 = 1667  (stale, shifted left by the slider centering offset of 800)

A window tiled to the left half still overlaps the stale box by accident, so the dock hides and everything looks fine. A window tiled to the right half starts at x = 1728, which is past the stale x2 = 1667, so no overlap is ever detected and the dock stays on top of the window. This matches the observations from @PixelcrafterEXE and @howl in the issue thread that the detection area behaves as if the dock started at the left edge of the screen. Users running the dock in panel mode never see the problem because the slider offset is genuinely 0 there.

Why not get_transformed_position()

I am aware this was already attempted in #2447, which read the position from this._box.get_transformed_position(). That method reflects the current visual position, including the slide animation, so the target box followed the dock while it was hiding and could end up off screen, causing the regressions tracked in #2501, and the change was then reverted in #2524.

This patch instead keeps the original, animation independent computation and only fixes the missing trigger: it additionally connects _updateStaticBox to notify::allocation on the slide container, so the box is recomputed whenever the layout repositions the slider. During the slide animation the recomputed values do not change, because the animation alters the slider size through its preferred size while the centering offset and the dock position stay constant, so the target box keeps pointing at the shown position of the dock and the #2501 regression is not reintroduced.

Testing

Verified on the affected setup above (live patching the running shell with the same signal connection):

• After the fix the target box matches the real dock position and the dock correctly dodges windows tiled to the right half.
• Windows tiled to the left half keep working as before.
• Autohide, hover reveal and the slide animations behave as before, with no oscillation or flicker observed, including after the dock is destroyed and recreated.

Thanks a lot for maintaining this extension, and thanks to everyone in the issue thread whose reports helped narrow this down.

Generated with Claude Code

[3v1n0]

Ok, I've changed it a bit, let's see how this goes!