Grid children are given LinearLayoutParams almost everywhere, so their margins are
taken from those as well as from GridLayoutParams, which gains margins.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
SetContentGravity centers the children, or moves them to the end, when they don't
fill the layout.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Lay out children across the layout direction within the layout's bounds rather than
its measured size, which differ when a parent clamps it. And count weighted
children's margins when growing to fit them.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Nothing used it, and it didn't work: it never set its own size, centered vertically
using the width, and didn't lay out its children.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Centering gravity centered in the whole cell, ignoring the margins, so a view with
uneven margins ended up off center.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
LinearLayout had a public padding member that only DisplayLayoutScreen set. Make it
private with a setter, and fix the measuring: the vertical retry used the horizontal
padding, the AT_MOST retries and the weighted children ignored it, and growing to fit
weighted children counted it twice.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Set by ViewGroup when a view is added, inserted or swapped in. Lets a view
find the scroll view it's in, for example.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Replaces the center-to-center scoring, which skipped a wide view between narrow
ones, since its center is far away even when its edge is right there. Now it
works like Android's FocusFinder: only views in the direction of the move are
candidates, ones in the origin's beam beat ones off to the side (going up or
down, unless those are in a nearer row), and otherwise the nearest wins, with
distance along the move weighted 13 times distance across it. Unlike Android,
the distance across is to the candidate's nearest edge rather than its center.
First/last and page moves keep their scoring.
Co-Authored-By: Claude Opus 5.5 <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
* 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
Henrik Rydgård