Summary

Settings rows with ui: "radiobuttons" (or "dropdown") render the raw stored pref value in the secondary text beneath the title. So a row with:

{"title": "Hero Image", "key": "hero_image", "ui": "radiobuttons",
 "ui_options": [("Lightning Piggy", "lightningpiggy"),
                ("Lightning Penguin", "lightningpenguin"),
                ("None", "none")]}

…displays "lightningpiggy" (internal value, no space) in the row, even though the picker activity itself correctly shows "Lightning Piggy" on the radio button. The label-to-value mapping only ever existed inside the picker; the list-view row had no access to it.

Same gap on the post-save path — when the user picks an option, the framework writes new_value directly to the value_label, so even a freshly-saved row reverts to "lightningpiggy".

Fix

Adds a small helper in settings_activity.py:

def _value_label_for(setting, stored_value):
    ui_options = setting.get("ui_options")
    if ui_options:
        for label, value in ui_options:
            if value == stored_value:
                return label
    return stored_value

Routed through in two places:

1. settings_activity.py list-view render — instead of value_text = stored_value, use value_text = _value_label_for(setting, stored_value). Default-value branch also routed through.
2. setting_activity.py post-save — instead of value_label.set_text(new_value), look up the label from ui_options first.

Tests

tests/test_settings_activity_label_mapping.py — 6 unit tests in one class on the new helper:

• Matched value returns label
• Unmatched value passes through (recoverable display for stale prefs)
• No ui_options passes through (textarea / freeform settings unaffected)
• Empty ui_options list passes through
• None value passes through (defensive — caller handles "(not set)" elsewhere)
• First-match-wins precedence with duplicate values (documents behavior)

$ bash tests/unittest.sh tests/test_settings_activity_label_mapping.py
Ran 6 tests
OK

Motivating case in the wild

LightningPiggyApp PR #26 (multi-wallet) adds a per-slot Hero Image setting with values "lightningpiggy" / "lightningpenguin" / "none". Without this framework fix, the Customise menu showed those raw values with no space ("lightningpiggy" instead of "Lightning Piggy").

I shipped a local closure-callback workaround there as a stopgap; once this PR lands, that workaround can come out and the row will be consistent on both initial display and post-save.

Hardware verification (this commit unchanged — verification done on existing tree)

Captured on a live device running multi-wallet LP with the unpatched (frozen) framework, then with the patched framework injected via exec(src, mpos.ui.settings_activity.__dict__) at the REPL.

Before — lightningpiggy raw value visible in the Hero Image row of Customise → exactly the bug this PR fixes:

┌──────────────────────────────────────┐
│ Balance Denomination                 │
│ ₿ symbol                             │
├──────────────────────────────────────┤
│ Hero Image                           │
│ lightningpiggy             ← raw     │
├──────────────────────────────────────┤
│ Theme                                │
│ Dark                                 │
└──────────────────────────────────────┘

After (label re-rendered with _value_label_for applied to the live widget):

┌──────────────────────────────────────┐
│ Balance Denomination                 │
│ ₿ symbol                             │
├──────────────────────────────────────┤
│ Hero Image                           │
│ Lightning Piggy            ← mapped  │
├──────────────────────────────────────┤
│ Theme                                │
│ Dark                                 │
└──────────────────────────────────────┘

PNG screenshots: /tmp/lp_customise_before_137.png and /tmp/lp_customise_after_137_simulated.png on the development host — see follow-up comment for the verification log.

Test plan

• All 6 unit tests pass on desktop
• No regression in existing settings rows that have no ui_options (textarea / freeform) — verified by the "passes through" tests
• Visual smoke-test on device: Lightning Piggy's Customise → Hero Image row currently shows raw "lightningpiggy" with the frozen framework, switches to "Lightning Piggy" after the patched _value_label_for is applied to the same widget (see screenshots in the verification comment below)
• Confirm-once-released: the simulated-after screenshot exercises the same code path that the framework patch will run (label.set_text(_value_label_for(...))); a single end-to-end "open Customise on a fresh boot of firmware that includes this PR" check will tick once SettingsActivity: render ui_options label instead of raw pref value #137 is in a release build

🤖 Generated with Claude Code