fix(overlay): stop SpectrumWidget from killing child-widget tooltips (#2355)#3209
Conversation
…ethersdr#2355) mouseMoveEvent() contains multiple QToolTip::hideText() call sites that fire whenever the cursor moves anywhere in the widget, including over SpectrumOverlayMenu buttons (MEM+, MEM▶, DAX). This immediately kills their tooltips the moment the mouse enters the button rect. Add an early-return guard: if the cursor is over a child widget and no drag is active, ignore the event and return so the child widget owns the pointer. Active drags are exempt — they always originate in the spectrum area, so childAt() returns null during a drag regardless. Fixes aethersdr#2355
There was a problem hiding this comment.
Thanks for the fix @M7HNF-Ian — clean diagnosis of a real UX bug and the patch is well-scoped.
The guard placement after the dragStatePublisher scope-exit (so it still runs via RAII on the early return) is the right call. I cross-checked anyDragActive() at src/gui/SpectrumWidget.cpp:1104 against every m_dragging* member declared in the header — all ten drag flags are covered, so the "active drags are exempt" property holds cleanly.
One small thing worth flagging (not a blocker):
Stale hover state when cursor enters a child. The early return skips the rest of mouseMoveEvent, which is also where TNF/spot-marker hover state and any tooltip the SpectrumWidget itself wants to show would normally update or clear. So if a spectrum tooltip (e.g. spot marker) was active and the user slides onto an overlay button, that prior tooltip may linger briefly until the next event clears it. In practice the child's own enter/move usually clobbers any lingering tooltip quickly enough that this isn't noticeable, but worth knowing if a related ticket pops up.
Otherwise, LGTM — fix matches the stated scope, doesn't touch any drag paths, and the comment in the code captures the invariant well. Nice catch on #2355.
🤖 aethersdr-agent · cost: $6.9970 · model: claude-opus-4-7
|
Claude here — merged, thanks @M7HNF-Ian. Two for two this session: this and #3210 are exactly the kind of surgical, well-diagnosed fixes that are a pleasure to review. Closes #2355. The childAt-guard pattern is going to be useful reference for any future "child widget over a tracking parent" tooltip issues; the comment in the code captures the invariant clearly. 73, Jeremy KK7GWY & Claude (AI dev partner) |
…ethersdr#2355) (aethersdr#3209) ## Problem `SpectrumWidget::mouseMoveEvent()` contains multiple `QToolTip::hideText()` call sites that fire whenever the cursor moves anywhere inside the widget. This includes movement over `SpectrumOverlayMenu` child buttons (MEM+, MEM▶, DAX) — their tooltips are dismissed the instant the mouse enters the button rect, making them effectively invisible. ## Fix Add an early-return guard immediately after the `dragStatePublisher` setup in `mouseMoveEvent()`: if `childAt()` returns a non-null widget and no drag is active, the event is ignored and returned early so the child widget owns the pointer (and therefore its own tooltip). Active drags are exempt from the guard — drags always originate in the spectrum area, so `childAt()` returns null during a drag regardless, and the guard is a no-op. ## Testing Tested locally: hovering over the MEM+, MEM▶, and DAX overlay buttons now shows their tooltips and holds them until the cursor leaves. Spectrum dragging (pan, zoom, TNF drag, slice drag) is unaffected. Fixes aethersdr#2355
Problem
SpectrumWidget::mouseMoveEvent()contains multipleQToolTip::hideText()call sites that fire whenever the cursor moves anywhere inside the widget. This includes movement overSpectrumOverlayMenuchild buttons (MEM+, MEM▶, DAX) — their tooltips are dismissed the instant the mouse enters the button rect, making them effectively invisible.Fix
Add an early-return guard immediately after the
dragStatePublishersetup inmouseMoveEvent(): ifchildAt()returns a non-null widget and no drag is active, the event is ignored and returned early so the child widget owns the pointer (and therefore its own tooltip).Active drags are exempt from the guard — drags always originate in the spectrum area, so
childAt()returns null during a drag regardless, and the guard is a no-op.Testing
Tested locally: hovering over the MEM+, MEM▶, and DAX overlay buttons now shows their tooltips and holds them until the cursor leaves. Spectrum dragging (pan, zoom, TNF drag, slice drag) is unaffected.
Fixes #2355