Current State
Summary
Corrected coordinates can be set from four places, but each one behaves differently. They all use the same CorrectedCoordsDialog, but each call site sets it up in its own way, has its own copy of the database-write code, and refreshes the UI differently afterwards. Users therefore see different dialogs and get inconsistent refresh behaviour, depending on where they clicked.
This issue also asks for a small feature: the dialog should show the distance and bearing from the original to the corrected coordinates.
Current behaviour
| Entry point |
"Original coordinates" panel |
When saved |
DB write |
Refresh afterwards |
Detail panel: Add / Edit / ✕ (cache_detail.py _edit_corrected_coords) |
❌ missing (no orig_lat/orig_lon passed) |
immediately |
_save_corrected_coords |
table row + map, via corrected_coords_changed |
Cache table context menu: Add / Edit / Clear corrected (cache_table.py _edit_corrected) |
✅ |
immediately |
_save_corrected |
reloads the row itself and emits the signal, so the row is reloaded twice; the detail panel is not refreshed |
Edit Cache dialog, Personal tab (waypoint_dialog.py _edit_corrected) |
✅ (from the unsaved form values) |
when the Edit Cache dialog is confirmed with OK |
_save_user_note |
via the edit-cache flow |
Map context menu: Set corrected here (mainwindow.py _on_set_corrected_from_map) |
no dialog |
immediately |
its own inline copy |
table row + map; the detail panel is not refreshed |
Problems
- The dialog looks different depending on where it's opened. Opened from the detail panel, it has no "Original coordinates" panel with copy buttons.
- The detail panel shows stale values. After setting or clearing corrected coordinates from the table or the map, the detail panel keeps showing the old values until another cache is selected.
MainWindow._on_corrected_coords_changed doesn't refresh the detail panel, unlike _on_found_status_changed. The table path also blocks selection signals during _reset_model_preserving_selection().
- The database write is copied four times, and the copies already differ:
flush() vs. commit()
is_corrected = lat is not None and lon is not None vs. is_corrected = True
- different eager-loading
- The table path reloads the cache twice: once in
_save_corrected, and again through refresh_cache_row when corrected_coords_changed fires.
Proposed Improvement
Proposed changes
Consolidation
New feature: distance and bearing in the dialog
Why: mystery-cache puzzle coordinates are typically within about 2 mi / 3.2 km of the posted coordinates. Showing the distance straight away catches typos, such as a wrong minute digit or the wrong hemisphere, before the coordinates are saved.
Acceptance criteria
- The dialog shows the same content from the detail panel, the cache table and the Edit Cache dialog, including the original coordinates and the distance/bearing line.
- Setting or clearing corrected coordinates from any entry point immediately updates the table row, the map pin and the detail panel, if it's showing that cache.
- There is one code path for the immediate-save database write.
- Unit tests:
- the distance/bearing line: shown for valid input, hidden for empty or invalid input, correct units with
use_miles
- the detail panel refreshes after a table or map change
- Existing tests in
test_corrected_coords_dialog.py and test_e2e_corrected_coords.py still pass.
Expected Benefits
No response
Current State
Summary
Corrected coordinates can be set from four places, but each one behaves differently. They all use the same
CorrectedCoordsDialog, but each call site sets it up in its own way, has its own copy of the database-write code, and refreshes the UI differently afterwards. Users therefore see different dialogs and get inconsistent refresh behaviour, depending on where they clicked.This issue also asks for a small feature: the dialog should show the distance and bearing from the original to the corrected coordinates.
Current behaviour
cache_detail.py_edit_corrected_coords)orig_lat/orig_lonpassed)_save_corrected_coordscorrected_coords_changedcache_table.py_edit_corrected)_save_correctedwaypoint_dialog.py_edit_corrected)_save_user_notemainwindow.py_on_set_corrected_from_map)Problems
MainWindow._on_corrected_coords_changeddoesn't refresh the detail panel, unlike_on_found_status_changed. The table path also blocks selection signals during_reset_model_preserving_selection().flush()vs.commit()is_corrected = lat is not None and lon is not Nonevs.is_corrected = True_save_corrected, and again throughrefresh_cache_rowwhencorrected_coords_changedfires.Proposed Improvement
Proposed changes
Consolidation
set_corrected_coords(gc_code, lat, lon)(None, Noneclears them), that writes theUserNoterow consistently. Use it from the detail panel, the cache table and the map._save_user_noteshould follow the sameis_correctedrule.orig_lat/orig_lonfrom the detail panel so the dialog looks the same from every entry point._on_corrected_coords_changedalso refreshes the detail panel when it's showing the affected cache, as_on_found_status_changeddoes._save_correctedand rely on the signal.New feature: distance and bearing in the dialog
Distance: 1.24 km · Bearing: 47° NEuse_miles(km/m vs. mi/ft, small distances in m/ft)distance_method(haversine/vincenty)filters/engine.py:distance_km,_bearing_deg(consider making it public) andbearing_direction_format_distancefromgui/dialogs/distance_bearing_dialog.pylang/*.py).Why: mystery-cache puzzle coordinates are typically within about 2 mi / 3.2 km of the posted coordinates. Showing the distance straight away catches typos, such as a wrong minute digit or the wrong hemisphere, before the coordinates are saved.
Acceptance criteria
use_milestest_corrected_coords_dialog.pyandtest_e2e_corrected_coords.pystill pass.Expected Benefits
No response