Problem
Turning the minimap on makes the editor's vertical scrollbar disappear. VS Code shows both —
the scroll slider is drawn over the minimap, and the minimap is the scrollbar's track.
Two separate causes, both vimcode-side:
A. quadraui computes a minimap scroll thumb and vimcode throws it away
MinimapLayout carries one:
// quadraui/src/primitives/minimap.rs:138
pub scrollbar: Option<Scrollbar>,
populated by Minimap::scroll_thumb() (:207, :221) — "None when the whole file
already fits (nothing to scroll)". So the geometry VS Code draws already exists, correctly
computed, in the layout vimcode receives.
vimcode never reads it: grep -n scrollbar src/render.rs | grep -i minimap returns nothing.
draw_minimap_strip (src/render.rs:4540) returns the MinimapLayout purely for click
routing and discards the scrollbar field.
B. The native GTK scrollbar's placement doesn't know the minimap exists
vimcode paints a real gtk4::Scrollbar widget per window (WindowScrollbars.vertical,
src/gtk/mod.rs:1044), positioned by sync_scrollbar_positions (:1407) from da_width and
calculate_group_window_rects. That function has no notion of the minimap at all — the
only occurrence of minimap in the whole of src/gtk/mod.rs is the single paint call at
:8461. So the native scrollbar and the minimap strip are both placed at the window's right
edge with nothing coordinating them.
Fix
Decide which one owns the right edge and make it explicit — do not leave both claiming it.
Preferred (VS Code's model): the minimap is the scrollbar track. Paint
MinimapLayout.scrollbar's thumb over the strip, and suppress or reposition the native
gtk4::Scrollbar for that window while the minimap is on. The drag handling already exists —
apply_minimap_click (src/render.rs:4593) seeks to a fraction of the file, which is exactly
what dragging the thumb should do, so this is mostly paint plus a placement decision.
Whichever way it goes, sync_scrollbar_positions must be told the reserved width so the two
stop overlapping.
Keep it platform-neutral per #35: the thumb geometry is quadraui's (scroll_thumb), the
Scrollbar primitive already has rasterisers in both backends — vimcode should be wiring, not
computing. If it turns out something is genuinely missing upstream, file it there rather than
adding scroll arithmetic to src/gtk/.
Acceptance
- With the minimap on and a file longer than the viewport, a scroll thumb is visible, and
its position tracks the viewport.
- With a file that fits entirely, no thumb (matching
scroll_thumb's documented None).
- Exactly one scroll affordance is visible per pane — assert the native scrollbar and the
minimap thumb are never both painted in the same column.
- Dragging the thumb scrolls the editor.
- TUI behaviour stated explicitly, even if that means "no change".
Related
Problem
Turning the minimap on makes the editor's vertical scrollbar disappear. VS Code shows both —
the scroll slider is drawn over the minimap, and the minimap is the scrollbar's track.
Two separate causes, both vimcode-side:
A. quadraui computes a minimap scroll thumb and vimcode throws it away
MinimapLayoutcarries one:populated by
Minimap::scroll_thumb()(:207,:221) — "Nonewhen the whole filealready fits (nothing to scroll)". So the geometry VS Code draws already exists, correctly
computed, in the layout vimcode receives.
vimcode never reads it:
grep -n scrollbar src/render.rs | grep -i minimapreturns nothing.draw_minimap_strip(src/render.rs:4540) returns theMinimapLayoutpurely for clickrouting and discards the
scrollbarfield.B. The native GTK scrollbar's placement doesn't know the minimap exists
vimcode paints a real
gtk4::Scrollbarwidget per window (WindowScrollbars.vertical,src/gtk/mod.rs:1044), positioned bysync_scrollbar_positions(:1407) fromda_widthandcalculate_group_window_rects. That function has no notion of the minimap at all — theonly occurrence of
minimapin the whole ofsrc/gtk/mod.rsis the single paint call at:8461. So the native scrollbar and the minimap strip are both placed at the window's rightedge with nothing coordinating them.
Fix
Decide which one owns the right edge and make it explicit — do not leave both claiming it.
Preferred (VS Code's model): the minimap is the scrollbar track. Paint
MinimapLayout.scrollbar's thumb over the strip, and suppress or reposition the nativegtk4::Scrollbarfor that window while the minimap is on. The drag handling already exists —apply_minimap_click(src/render.rs:4593) seeks to a fraction of the file, which is exactlywhat dragging the thumb should do, so this is mostly paint plus a placement decision.
Whichever way it goes,
sync_scrollbar_positionsmust be told the reserved width so the twostop overlapping.
Keep it platform-neutral per #35: the thumb geometry is quadraui's (
scroll_thumb), theScrollbarprimitive already has rasterisers in both backends — vimcode should be wiring, notcomputing. If it turns out something is genuinely missing upstream, file it there rather than
adding scroll arithmetic to
src/gtk/.Acceptance
its position tracks the viewport.
scroll_thumb's documentedNone).minimap thumb are never both painted in the same column.
Related
same strip geometry, so expect to sequence them.
popup; worth a look while in this code, but not in scope here.