Fix dock hover animation on monitors with a non-zero offset - #355
Open
benny-png wants to merge 1 commit into
Open
Fix dock hover animation on monitors with a non-zero offset#355benny-png wants to merge 1 commit into
benny-png wants to merge 1 commit into
Conversation
dock.struts.x (and .y in the vertical branch) was only ever assigned inside the `autohide_dash` branch, so with autohide disabled the strut actor kept its default position of 0. _isWithinDash() hit-tests the pointer against the strut rect, so on a multi-monitor layout where the dock's monitor has a non-zero offset the rect sits over a different monitor and the pointer is never considered to be inside the dock. Icon magnification therefore never triggers. This is invisible on a single-monitor setup because the offset is 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom
With more than one monitor connected, icon magnification never triggers — hovering the dock does nothing. The dock renders and its icons stay clickable; only the animation is dead. Everything works again as soon as the setup is back to a single monitor.
This only reproduces when autohide is disabled.
Root cause
In
animator.js,dock.struts.xis assigned only inside theautohide_dashbranch:With autohide off, that branch never runs and the line that would set it is commented out, so
struts.xkeeps its default of0._isWithinDash()(dock.js) hit-tests the pointer against exactly that rect:and
Animator.animate()gates all magnification on its result:So on a layout where the dock's monitor has a non-zero x offset, the strut rect sits over a different monitor than the one the dock is drawn on. The pointer is never inside it,
animatedstaysfalse, and no icon ever scales.On a single monitor the offset is
0, which is why the missing assignment is invisible there.The vertical branch has the same problem for
y(// dock.struts.y = dock.y;, same file), so a left/right dock on a monitor with a non-zero y offset should fail the same way.Fix
Assign the strut origin in the non-autohide case, as an
elseon the existing branch so the autohide values are not overwritten. Both orientations changed for symmetry.Because the new code lives in an
elseofif (dock.extension.autohide_dash), this is a no-op when autohide is enabled.Verification
Ubuntu, GNOME Shell 46.0, X11, dock at bottom, autohide disabled, dodge enabled. Two 1920x1080 monitors, the dock's monitor being the primary at offset
+1920+413:Also confirmed as a side effect: with the strut rect now on the correct monitor, maximized windows on that monitor stop above the dock instead of extending underneath it, which is what
affectsStrutswas supposed to be doing.Testing was on v92 with the patch applied by hand; the surrounding code in both branches is identical at HEAD (v100), where this diff is taken from.
Not tested: vertical (left/right) dock positions — that hunk is the symmetric change and is reasoned-about rather than reproduced. Wayland, and any autohide-enabled configuration, were not exercised; per the above the latter is untouched by this change.