Make the rail reset zero the sensor in live and the display in replay

The replay view disabled a control whose display reset is exactly what an
operator wants there, and the bare "Reset" hid that the live one zeroes the
sensor tracker; the label, tooltip and status line now name the target, and
Ctrl+R follows the view. Verified with the studio suite, ui_check (628
checks) and real-GL rail snapshots of both views.
This commit is contained in:
ykcheungab
2026-10-04 11:09:22 +08:00
parent aa526c62a9
commit 6fb2f72c6e
9 changed files with 525 additions and 50 deletions
+26 -5
View File
@@ -14,7 +14,8 @@ elements are supposed to exist*. These tests make that claim falsifiable against
permanently skipped;
* the transport group the manifest declares is the behaviour of a *live* session: a running
session keeps the tracker reset available and reads "pause", and a paused session reads
"resume". That is the defect class this artifact exists to prevent — a state assertion
"resume"; in the replay view the same declared reset is the display reset and says so.
That is the defect class this artifact exists to prevent — a state assertion
about widgets passing while the visible result is wrong.
A deliberate asymmetry: the existence assertions are hard (a missing element fails), while
@@ -248,12 +249,18 @@ def test_the_transport_group_matches_the_live_session_states(make_window):
assert reset is window.toolbar.btn_reset
assert window._session_phase == "running", window._session_phase
# A running session: the transport reads pause and the reset is available.
# A running session: the transport reads pause and the reset is available —
# and it says which of the two things it acts on (the sensor tracker).
assert transport.isChecked(), (
"a running session must show the transport engaged"
)
assert transport.text() == t("toolbar.pause"), transport.text()
assert reset.isEnabled(), "a running session must offer the tracker reset"
assert window.toolbar.reset_target() == "sensor", (
"the live view's reset is the sensor tracker's"
)
assert reset.text() == t("toolbar.reset_sensor"), reset.text()
assert reset.toolTip() == t("toolbar.reset_sensor_tip"), reset.toolTip()
assert stop.isEnabled(), "a running session must offer stop"
# Paused: the transport reads resume, and the device action stays available.
@@ -286,7 +293,13 @@ def test_the_transport_group_matches_the_live_session_states(make_window):
def test_the_transport_of_the_replay_view_is_not_the_device_reset(make_window):
"""The same controls, the other view: an idle transport and no device to zero."""
"""The same controls, the other view: an idle transport, and a reset that resets the display.
The manifest declares one ``reset`` element for both views, so this is where the
claim that it means *one* thing per view is checked: in the replay view it is the
display reset (named as such, and there is no device for it to touch), not a
disabled control and not a tracker zero.
"""
window = _window(make_window, "box", "replay")
try:
by_id = elements.manifest().by_id()
@@ -294,8 +307,16 @@ def test_the_transport_of_the_replay_view_is_not_the_device_reset(make_window):
reset = elements.resolve(window, by_id["reset"])
assert not transport.isChecked()
assert transport.text() == t("toolbar.playback"), transport.text()
assert not reset.isEnabled(), (
"reset is offered where there is no tracker to zero"
assert window.toolbar.reset_target() == "display", (
"the replay view's reset is the display's: this view owns no device"
)
assert reset.isEnabled(), (
"the display reset is available in the replay view (the reported defect)"
)
assert reset.text() == t("toolbar.reset_display"), reset.text()
assert reset.toolTip() == t("toolbar.reset_display_tip"), reset.toolTip()
assert window.act_reset.text() == t("menu.reset_display"), (
"Ctrl+R is the same control on a second surface and must be named the same way"
)
finally:
window.close()