NativeKey calls KeyEventToFocusMoves directly on the input thread, while
ProcessHeldKeys iterates heldKeys on the UI thread, which tripped an
iterator assert in debug builds. ProcessHeldKeys also dispatched key
events mid-iteration, where a handler calling EnableFocusMovement(false)
would clear the set under it. Now it collects due repeats under the lock
and dispatches them after.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
With no type-to-search active, Backspace goes to the parent directory. Never
on a repeat, so holding it doesn't climb to the root. Not every platform
flags repeats, so the browser also tracks whether it's held.
Windows raw input now flags auto-repeated key downs as IS_REPEAT, like
Android and UWP, and forgets the held keys it releases on losing focus. The
UI drops OS repeats of a key it's already repeating itself, so held arrows
don't double up (they were dropped before too, a step later).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Refresh already focused a game it was asked to. Now it does the same for
directories, and keeps the request until a listing that was still loading
has arrived. UI::ScrollFocusedViewIntoView scrolls the focused view into
sight once it's been laid out, since SetFocus alone doesn't scroll.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On Windows, a key released while Alt is held comes as WM_SYSKEYUP, which
raw input dropped, so after Alt+Up the UI kept the arrow held and the focus
kept moving. Handle it like WM_KEYUP. Alt+arrows also no longer move the
focus, since they're shortcuts.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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
Reported by Flide, thanks!
However, there's some underlying bug in screen focus tracking, this just works around it by checking for top screen in a more reliable way.
* Rename LogType to Log
* Explicitly use the Log:: enum when logging. Allows for autocomplete when editing.
* Mac/ARM64 buildfix
* Do the same with the hle result log macros
* Rename the log names to mixed case while at it.
* iOS buildfix
* Qt buildfix attempt, ARM32 buildfix
* Move and rename file_util/fd_util to Common/File/FileUtil and DirListing
Let's also move net while we're at it.
Move the ZIM/PNG loaders over to Common.
Move the UI framework into Common
iOS buildfix
* Buildfix
* Buildfixes
* Apple buildfix
* This typo again..
* UWP buildfix
* Fix build of PPSSPPQt, such as it is (it's not in good condition...)
* Guess what? Another buildfix.
