You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you grab a slice's passband and drag it to the edge of the panadapter to
tune across the band, the view should keep scrolling smoothly so you can sweep
the whole range in one gesture. Today you effectively have to zoom in first.
Reported by a user as a feature wish.
Related: this is the mouse drag-to-tune method floated in #1474 (umbrella for
"additional ways to change slice frequency"), but as a refinement to the existing drag rather than a new method. Touches the same mouseMoveEvent
surface as #3444 (drag event overload) — kept separate from that bug.
Current behaviour (measured)
A slice drag already pans a little at the edge, but it creeps and stutters
("rubber band", harder going down than up):
The slice drag emits incrementalTuneRequested per mouse-move; the edge
follow is revealFrequencyIfNeeded, a position controller — it nudges the
slice a bit past the trigger margin (kIncrementalTriggerEdgeMarginFrac=0.05).
At the border the cursor can't move past the frame, so the overshoot that
drives the nudge is tiny and self-limiting (as the center follows, the
cursor frequency follows with it). Measured: ~0.0027 MHz/tick regardless
of how hard you push → ~0.1×span/s. Crossing a band takes ~20 s.
A velocity controller for the edge: while the cursor sits in the edge zone,
a ~30 Hz timer pans at a speed that scales with edge depth and ramps up with
hold time, keeping the slice parked just inside the leading edge so it stays
visible while the band scrolls under it. The pan+tune go through a dedicated
path that bypasses reveal (so it can't fight). Measured after the fix: dMhz=0.00182 /tick at full depth+ramp = 1.2×span/s, center monotonic, no
jump-back, symmetric L/R; slice parked at the 5% boundary (sliceX=243/4617).
AETHER_NO_DRAG_EDGEPAN=1 restores the legacy reveal-only behaviour for A/B.
Velocity defaults (top speed / ramp / interval) are exposed as env overrides so
the feel can be tuned without a rebuild — these defaults are a UX decision
and need maintainer sign-off (AGENTS.md: maintainer is the sole UX authority).
Notes
This is a UX behaviour change, so per AGENTS.md it is raised as an issue for
maintainer direction first; the PR notes the velocity defaults need review.
What would you like?
When you grab a slice's passband and drag it to the edge of the panadapter to
tune across the band, the view should keep scrolling smoothly so you can sweep
the whole range in one gesture. Today you effectively have to zoom in first.
Reported by a user as a feature wish.
Related: this is the mouse drag-to-tune method floated in #1474 (umbrella for
"additional ways to change slice frequency"), but as a refinement to the
existing drag rather than a new method. Touches the same
mouseMoveEventsurface as #3444 (drag event overload) — kept separate from that bug.
Current behaviour (measured)
A slice drag already pans a little at the edge, but it creeps and stutters
("rubber band", harder going down than up):
incrementalTuneRequestedper mouse-move; the edgefollow is
revealFrequencyIfNeeded, a position controller — it nudges theslice a bit past the trigger margin (
kIncrementalTriggerEdgeMarginFrac=0.05).drives the nudge is tiny and self-limiting (as the center follows, the
cursor frequency follows with it). Measured: ~
0.0027MHz/tick regardlessof how hard you push → ~0.1×span/s. Crossing a band takes ~20 s.
the flag side, so reveal kicks in before a velocity takeover and fights it →
the one-sided stutter/jump-back.
Proposed behaviour (implemented, validated)
A velocity controller for the edge: while the cursor sits in the edge zone,
a ~30 Hz timer pans at a speed that scales with edge depth and ramps up with
hold time, keeping the slice parked just inside the leading edge so it stays
visible while the band scrolls under it. The pan+tune go through a dedicated
path that bypasses reveal (so it can't fight). Measured after the fix:
dMhz=0.00182/tick at full depth+ramp = 1.2×span/s, center monotonic, nojump-back, symmetric L/R; slice parked at the 5% boundary (
sliceX=243/4617).AETHER_NO_DRAG_EDGEPAN=1restores the legacy reveal-only behaviour for A/B.Velocity defaults (top speed / ramp / interval) are exposed as env overrides so
the feel can be tuned without a rebuild — these defaults are a UX decision
and need maintainer sign-off (AGENTS.md: maintainer is the sole UX authority).
Notes
This is a UX behaviour change, so per AGENTS.md it is raised as an issue for
maintainer direction first; the PR notes the velocity defaults need review.