Files
ppsspp/Common
Henrik RydgårdandClaude Opus 5 ea1ad8ffed UI: Tab and Shift+Tab move focus through the view hierarchy
Unlike the directional moves, this doesn't look at where anything ended up on
screen - it walks the hierarchy in the order views were added, flattening nested
groups in place. That's what makes it predictable in the layouts where "what's
to the right of this" has no good answer.

A view is a stop if it's focusable and enabled, the same test the directional
moves apply, so the two agree on what's reachable. Hidden subtrees are skipped
whole, which is what keeps a TabHolder's inactive tabs - V_GONE rather than
removed - out of the order without any special casing. Containers are gated on
visibility only, not enabled, matching Key/Touch/Axis: disabling a container
doesn't stop its children being interactive anywhere else either.

Ctrl+Tab stays with ChoiceStrip, which uses it to switch tabs.

focusMoves now holds FocusMove rather than raw keycodes, so the direction is
decided in one place while the modifiers are still around, and a held key
repeats in the direction it was originally pressed with - the synthesized repeat
has no modifiers of its own. That also retires the keycode switch in
UpdateViewHierarchy and IsScrollKey, which had no other callers.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SfY7iFJEjmRXf1XGrTs4MF
2026-08-27 20:52:20 +02:00
..
2025-02-11 10:43:39 -06:00
2026-08-24 09:30:44 +02:00
2026-08-10 04:59:55 -04:00
2025-08-31 13:37:43 +02:00
2026-01-30 14:10:32 +01:00
2026-03-30 11:34:19 -06:00
2026-08-24 09:30:44 +02:00
2024-07-26 14:22:31 +02:00
2025-08-31 13:37:43 +02:00
2026-05-16 10:40:08 +02:00
2026-07-27 21:33:14 +02:00
2026-07-27 18:37:28 +02:00