Skip to content

Corrected coordinates: consolidate the four entry points, and show distance and bearing from the original coordinates #936

Description

@nagisml

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

  1. The dialog looks different depending on where it's opened. Opened from the detail panel, it has no "Original coordinates" panel with copy buttons.
  2. 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().
  3. 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
  4. 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

  • Add one shared helper, e.g. set_corrected_coords(gc_code, lat, lon) (None, None clears them), that writes the UserNote row consistently. Use it from the detail panel, the cache table and the map.
  • The Edit Cache dialog keeps its current behaviour (changes are saved when the dialog is confirmed with OK), because it's a form dialog. _save_user_note should follow the same is_corrected rule.
  • Pass orig_lat/orig_lon from the detail panel so the dialog looks the same from every entry point.
  • _on_corrected_coords_changed also refreshes the detail panel when it's showing the affected cache, as _on_found_status_changed does.
  • Remove the table's own reload from _save_corrected and rely on the signal.

New feature: distance and bearing in the dialog

  • When the original coordinates are known and the input parses as valid coordinates, show the distance and bearing from the original to the corrected position below the corrected-coordinates panel. For example:
    Distance: 1.24 km · Bearing: 47° NE
  • Update it live as the user types; hide it when the input is empty or can't be parsed.
  • Respect the user's settings:
    • distance: use_miles (km/m vs. mi/ft, small distances in m/ft)
    • distance method: distance_method (haversine/vincenty)
  • Reuse the existing helpers rather than adding new maths:
    • filters/engine.py: distance_km, _bearing_deg (consider making it public) and bearing_direction
    • _format_distance from gui/dialogs/distance_bearing_dialog.py
  • Translated labels for all supported languages (lang/*.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

  • 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions