mirror of
https://github.com/bryanthaboi/gen1recomp.git
synced 2026-08-12 08:21:02 +02:00
Marcus Pereira
cc67be341f
On a window too short for the stacked single-column layout -- a phone, or a narrow desktop window -- the ROM / SAVE FILES / Play / SAVE SLOT stack ran past the bottom of the window while the footer stayed pinned there and drew over it. Nothing clipped the panel and nothing scrolled it, so the overflow was unreachable. Everything under the tab bar (panel, updater banner, footer) is now one scrolling column, used only when it is taller than the room below the tab bar. The strip, logo and tab bar stay pinned, so navigation is always on screen, and the footer is laid out downward from footerTop right after the content instead of upward from the window bottom. - RomImporter.pageScrollFor is the whole decision, pure and covered by tests/engine/launcher_page_scroll.lua. A window that grows back drags the offset down with it, so the page never stays parked past its own end. - The panels return their natural height as they draw, so the measurement is the previous frame's: the same one-frame settle the slot and mod lists already rely on. - One scroll axis at a time. While the page scrolls, the panels draw paged: the slot and mod lists take their natural height, keep no inner scroll region and report a max of 0, so wheel, right stick and drag all move the page. Two-column layouts do not overflow, paged stays false, and every one of these behaves exactly as before. - inside() and _ptIn() reject a rect that scrolled out of the viewport, so a control that slid under the tab bar cannot be clicked through it. Tab chips are pinned and exempt. pageScroll resets on a tab change. Android had no scroll gesture at all: the launcher is handed no move events (main.lua forwards neither touchmoved nor mousemoved while it is up) and its mouse emulation was never trusted, which is what "no reliable pointer polling" referred to. That was survivable while every scroll region was an inner list, and useless once the page itself scrolls, since a phone is exactly where it overflows. love.touch is pollable, so _pointerHold reads the first active touch there and hands _updateSlotDrag the same (held, y) pair the mouse gives on desktop. Slot rows and mod toggles consequently arm on press and commit on release on Android too, matching desktop, so a swipe that starts on a card scrolls instead of selecting it. All of it is gated on touchPollable: without love.touch every Android path is exactly what it was. conf.lua also grows minwidth/minheight (480x360) for the desktop window, under which the cards stop being readable. Mobile is fullscreen and ignores it. Verified on the Android emulator (1080x2400) against a build of the parent commit: before, the footer painted over the SAVE SLOT card with no way to reach it; after, the page pans by touch and the footer is reachable and intact.