Skip to content

#554: [retry] #448-G: GTK scroll wheel scrolls editor text in the wrong (inverted) direction - #655

Merged
JDonaghy merged 1 commit into
developfrom
issue-554-448-g-gtk-scroll-wheel-scrolls-editor-te
Aug 10, 2026
Merged

#554: [retry] #448-G: GTK scroll wheel scrolls editor text in the wrong (inverted) direction#655
JDonaghy merged 1 commit into
developfrom
issue-554-448-g-gtk-scroll-wheel-scrolls-editor-te

Conversation

@JDonaghy

Copy link
Copy Markdown
Owner

Closes #554

Automated PR opened by coordinator for review of issue #554.

Wheel-down scrolled the editor text up (and vice-versa) since the #540
Relm4->ShellApp migration.

Two conventions meet at `ShellApp::handle`'s `UiEvent::Scroll` arm and
they disagree:

  * GDK's `EventControllerScroll` reports positive `dy` = wheel down.
  * `UiEvent::Scroll.delta` is quadraui's convention, positive y = up.
    `quadraui::gtk::events::gdk_scroll_to_uievent` is what flips one into
    the other -- it builds `ScrollDelta::new(dx, -dy)`.

Everything downstream of `Msg::MouseScroll` -- the `delta_y > 0.0 =>
dir = 1` viewport step, the `picker_scroll` sign, `handle_terminal_scroll`'s
"> 0 = toward live" policy -- was written against GTK's raw polarity and is
byte-identical to its pre-migration form. Pre-migration the Relm4
`connect_scroll` closure fed it GTK's `dy` directly and *separately* pushed
the negated `gdk_scroll_to_uievent` form onto the backend event queue. The
migration deleted that closure and left the runner's already-negated
`UiEvent::Scroll` as the only source, so the second negation vanished and
every wheel notch reached the engine with the sign flipped.

Fix: negate y back to GTK-raw at that one boundary. Only y -- `dx` is
passed through unchanged by the translator, so `delta.x` is already raw.
The translator itself is untouched: TUI and macOS share it and were never
wrong.

Tests (src/gtk/testing.rs, in-crate GtkDriver harness):

  * New `gdk_wheel_down_scrolls_the_viewport_down_not_up` drives the real
    `gdk_scroll_to_uievent` rather than a hand-built `UiEvent`, so the whole
    chain GDK dy -> UiEvent -> Msg -> engine is covered in one test. It
    asserts both halves: the translator's polarity (dy=+1 -> delta.y=-1)
    and the resulting engine motion (scroll_top rises, then falls on the
    opposite notch). Asserting either half alone stays green with the bug.
  * `wheel_scrolls_the_pane_under_the_pointer_not_the_focused_one` had a
    `wheel_down_at` helper dispatching `delta.y = +1.0` while asserting
    scroll_top *increases* -- green only because of this very inversion.
    Corrected to `-1.0`.

Both go red on the pre-fix code; full `cargo test` (GUI feature on,
headless) is green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@JDonaghy
JDonaghy merged commit 10cf256 into develop Aug 10, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

#448-G: GTK scroll wheel scrolls editor text in the wrong (inverted) direction

1 participant