René's URL Explorer Experiment

Title: SettingsActivity: render ui_options label instead of raw pref value by bitcoin3us · Pull Request #137 · MicroPythonOS/MicroPythonOS · GitHub

Open Graph Title: SettingsActivity: render ui_options label instead of raw pref value by bitcoin3us · Pull Request #137 · MicroPythonOS/MicroPythonOS

X Title: SettingsActivity: render ui_options label instead of raw pref value by bitcoin3us · Pull Request #137 · MicroPythonOS/MicroPythonOS

Description: 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: 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. setting_activity.py post-save — instead of value_label.set_text(new_value), look up the label from ui_options first. Case Before After ui_options matches stored value "lightningpiggy" "Lightning Piggy" No ui_options (textarea, etc.) raw value raw value (unchanged) Stored value not in current ui_options (stale pref) raw value raw value (visible, recoverable, not collapsed to "(not set)") default_value rendered with "(defaults to X)" raw default_value mapped label 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 #137 is in a release build 🤖 Generated with Claude Code

Open Graph Description: 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": "...

X Description: 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: {&quot...

Opengraph URL: https://github.com/MicroPythonOS/MicroPythonOS/pull/137

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width