Problem
In TUI, clicking on the explorer scrollbar track (anywhere on the column, not just on the thumb itself) jumps the view to that scroll position — standard "page click" behaviour. In GTK, the same click does nothing; only dragging the thumb scrolls.
Repro
- GTK: open explorer in a directory with more files than fit on screen.
- Click somewhere on the scrollbar column that's NOT on the thumb (above or below it).
- Expected (TUI parity): viewport jumps so the thumb covers the clicked position.
- Actual: no change.
Suspected Cause
The GTK explorer `GestureDrag` handler (src/gtk/mod.rs:~2244) only fires on drag-update + drag-end. For a click-without-drag on the track, drag-begin fires but then drag-end immediately follows with no motion, so the existing handler treats it as a no-op.
`drag-begin` could jump-scroll to the click position before recording `start_top`, matching TUI behaviour. Or migrate the GTK explorer scrollbar to the cross-backend `DragState` + `dispatch_mouse_down` pattern (commits a02eff9, 0f3e0d0) where click-on-track jumps + arms drag in one step — like the GTK palette scrollbar after #190 was fixed.
Files
- `src/gtk/mod.rs` — `GestureDrag` setup around line 2244, `connect_drag_begin` is the right place to add the jump-scroll.
Priority
Minor UX gap. Workaround: drag the thumb. Pre-existing.
Related
Fits the cross-backend event-routing arc (a02eff9 / 0f3e0d0 / b169ca4 / bad14f0 / 03a3339). The GTK explorer scrollbar is one of the remaining scrollbars not yet migrated to `DragState::ScrollbarY`.
Problem
In TUI, clicking on the explorer scrollbar track (anywhere on the column, not just on the thumb itself) jumps the view to that scroll position — standard "page click" behaviour. In GTK, the same click does nothing; only dragging the thumb scrolls.
Repro
Suspected Cause
The GTK explorer `GestureDrag` handler (src/gtk/mod.rs:~2244) only fires on drag-update + drag-end. For a click-without-drag on the track, drag-begin fires but then drag-end immediately follows with no motion, so the existing handler treats it as a no-op.
`drag-begin` could jump-scroll to the click position before recording `start_top`, matching TUI behaviour. Or migrate the GTK explorer scrollbar to the cross-backend `DragState` + `dispatch_mouse_down` pattern (commits a02eff9, 0f3e0d0) where click-on-track jumps + arms drag in one step — like the GTK palette scrollbar after #190 was fixed.
Files
Priority
Minor UX gap. Workaround: drag the thumb. Pre-existing.
Related
Fits the cross-backend event-routing arc (a02eff9 / 0f3e0d0 / b169ca4 / bad14f0 / 03a3339). The GTK explorer scrollbar is one of the remaining scrollbars not yet migrated to `DragState::ScrollbarY`.