fix: menu can be operated with a remote control (#91)

[compot-dev]

Closes #91.

Cause (reproduced on Aceline-1 with input keyevent): the menu opens on OK, but the layout itself holds the focus (#65 gives it focus so that Escape works after a touch; on the AG-216 the popup also starts in touch mode). A D-pad key then searches for the next focusable view beside the focused one, and every item lies inside the layout's rectangle — so nothing ever got the focus, and OK/arrows did nothing.

Fix

• While the layout is focused, the first D-pad / OK / Tab key moves the focus to the active item (current slot, Q in multi-view, U in the UDP view) instead of being lost.
• Opened from a remote (not in touch mode), the active item gets the focus right away.
• Menu items are explicitly focusable (not only through the clickable default of Android 8+).
• Escape and Back still close the menu.

Device check: input keyevent sequence OK → RIGHT ×n → DOWN → OK, in single view and multi-view (to be added to the next test round).

[compot-dev]

/review

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Remote navigation lacks a device check ✓ Resolved

Description

The PR changes showMenu and focus handling but adds no AG-216 device check or input keyevent
sequence. The next test round therefore has no committed verification that OK, D-pad navigation, and
menu response work on the target device.

Code

android/app/src/main/java/com/openipc/decoder/MenuManager.java[R126-127]

+            mFocusItem = focusItem(quadEnabled, mActive);
+            focusForKeys(mMenuLayout, mFocusItem);

Evidence

The checklist requires the next test round to include an AG-216 input keyevent sequence and verify
menu response. The changed PR content only adds production focus and navigation handling; no
device-check or keyevent verification is included.

Device D-pad keyevent check
android/app/src/main/java/com/openipc/decoder/MenuManager.java[126-127]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR implements remote-control menu handling but does not add the requested AG-216 device check using an `input keyevent` navigation sequence.
## Fix Focus Areas
- android/app/src/main/java/com/openipc/decoder/MenuManager.java[126-127]
## Recommended Fix
Add the AG-216 device-check procedure to the next test round, including OK to open the menu, repeated RIGHT navigation, DOWN, and OK in both single-view and multi-view modes, and verify that the expected menu action occurs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. OK cannot select items in touch mode ✓ Resolved

Description

The layout’s dispatchKeyEvent() consumes Center and Enter even when item.requestFocus() fails,
because createItem() makes menu items focusable but not focusable in touch mode. If the popup
remains in touch mode when those keys arrive, the layout keeps focus and subsequent presses take the
same branch without reaching an item’s click handler.

Code

android/app/src/main/java/com/openipc/decoder/MenuManager.java[R145-148]

+                    if (event.getAction() == KeyEvent.ACTION_DOWN && item != null) {
+                        item.requestFocus();
+                    }
+                    return true;

Evidence

Touch-mode initialization focuses the layout; the new branch handles Center and Enter, attempts to
focus an item, and returns true regardless of whether focus moves. Menu items receive
setFocusable(true) but not touch-mode focusability, while their actions are attached as click
listeners.

android/app/src/main/java/com/openipc/decoder/MenuManager.java[143-149]
android/app/src/main/java/com/openipc/decoder/MenuManager.java[310-313]
android/app/src/main/java/com/openipc/decoder/MenuManager.java[325-348]
android/app/src/main/java/com/openipc/decoder/MenuManager.java[196-218]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The popup layout consumes Center and Enter while focused, even if its attempt to focus a menu item fails in touch mode. Repeated presses then cannot activate an item.
## Fix Focus Areas
- android/app/src/main/java/com/openipc/decoder/MenuManager.java[143-149]
- android/app/src/main/java/com/openipc/decoder/MenuManager.java[343-348]
## Recommended Fix
Make menu items eligible for focus in touch mode before requesting focus, and avoid consuming a navigation key as a successful focus transfer when `requestFocus()` fails. Verify Center and Enter after a touch-opened popup can reach an item’s click handler.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can turn these tips off under Display > Comment parts

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[compot-dev]

Qodo review — decisions:

1. Remote navigation lacks a device check — accepted: the input keyevent sequence is now in LABORATORY.md (Other checks → Menu with a remote). Run on Aceline-1 with this PR's build (43a814c): OK opened the menu with the focus on Q (multi-view); RIGHT ×3 → 1, 2, 3; DOWN → Exit; UP → 4; LEFT → 3; OK → single view, slot 3. In single view OK opened the menu with the focus on 3, BACK closed it; LEFT ×3 to Q and OK → multi-view again.
2. OK cannot select items in touch mode — accepted: the key is consumed only when requestFocus() really moved the focus; otherwise it goes on as before. (Key events normally leave touch mode before they are dispatched, so the item becomes focusable.)

Also: LABORATORY notes that Wi‑Fi on Aceline-1 is switched off (wired only).

[qodo-free-for-open-source-projects]

Qodo review — decisions:

1. Remote navigation lacks a device check — accepted: the input keyevent sequence is now in LABORATORY.md (Other checks → Menu with a remote). Run on Aceline-1 with this PR's build (43a814c): OK opened the menu with the focus on Q (multi-view); RIGHT ×3 → 1, 2, 3; DOWN → Exit; UP → 4; LEFT → 3; OK → single view, slot 3. In single view OK opened the menu with the focus on 3, BACK closed it; LEFT ×3 to Q and OK → multi-view again.
2. OK cannot select items in touch mode — accepted: the key is consumed only when requestFocus() really moved the focus; otherwise it goes on as before. (Key events normally leave touch mode before they are dispatched, so the item becomes focusable.)

Also: LABORATORY notes that Wi‑Fi on Aceline-1 is switched off (wired only).

Thanks for the update. The validation evidence addresses both open findings:

• finding 1 — Remote navigation lacks a device check: the Aceline-1 input keyevent checks are now documented and cover single- and multi-view navigation.
• finding 2 — OK cannot select items in touch mode: the focus-transfer guard is in place, with the expected key-dispatch behavior confirmed.

Noted that Aceline-1 was tested over wired Ethernet with Wi‑Fi disabled.