mirror of
https://github.com/DarkFlippers/unleashed-firmware.git
synced 2026-11-13 10:27:37 +00:00
Mykhailo ShevchukandClaude Opus 5
56ec776a04
* GUI: give applications a way to cover their own startup Fixes #1124. An application owns no pixels until its first view switch - view_dispatcher_alloc leaves the ViewPort disabled and only view_dispatcher_set_current_view enables it - so anything it does before that is drawn as whatever was on screen before, usually the menu it was launched from. A survey of the 28 runnable apps found about fifteen do blocking work in that window, with three different idioms for covering it and roughly 150-200 bytes of glue per app that used one. Two changes, both in the GUI service. view_dispatcher_run() now discards input that arrived before it. Nothing drains the queue until the loop starts, and handle_input binds an event to whichever view is current when it is processed rather than when it arrived, so those keys were replayed into a screen the user never saw - on a variable item list a stray Left or Right silently changed a setting. This one needs no API and covers every application at once. view_dispatcher_show_loading() puts up the same animation the loader uses. The view is allocated on first use and belongs to the dispatcher, so unlike the hand-rolled version it takes no view id, needs no struct field, and nothing has to remember to remove or free it. Switching to any view of your own dismisses it. Converted the two apps this matters most for: Desktop settings, which was the hand-rolled instance, and Archive, whose browser reads the favourites file and stats every entry before its first switch and is the slowest first screen in the firmware. Archive keeps its own loading popup for runtime overlays - that is a ViewStack on top of a live view, which is a different thing. Costs 92 bytes of firmware and gives back 136 in desktop_settings.fap alone, so it pays for itself at the first converted app. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * GUI: drop only the input the loading screen swallowed From the review. Two corrections, both to the first commit's input handling. Discarding everything queued before view_dispatcher_run() was too broad. The premise - that those keys were pressed on a screen the user never saw - only holds when the app has a loading screen up. The desktop is the counterexample: it switches to its final view, then does an SD stat and a Secure Enclave verification, and only then runs its loop. Keys pressed there are pressed on the screen the user is looking at, and dropping them would have made the first press after boot vanish. That reset is gone. What replaces it drops input on the way out of the loading view, which is the case the justification actually describes, and covers a show_loading() from inside a running loop as well - the retry path in desktop settings, for one - where there was no protection at all. That has a hazard of its own the review caught: a key already counted in ongoing_input owns a Release that the drain at the end of view_dispatcher_run() waits for, and eating it would hang the application on exit. So it only fires when no sequence is in flight; one that is, is bound to the loading view and the existing delivery check already keeps it off the next view. The dropped events are logged like every other discard path in the file. Archive asks for the loading screen from its entry point now, not from the browser scene. That scene is re-entered from five others, where a view of ours is already current and holding the previous screen is both the old behaviour and the better one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * GUI: fold the duplicated loading view lookup Also drops the debug log on the discard: it fires on an expected bulk drop rather than a protocol violation, unlike the sibling paths in this file that log, and furi_message_queue_reset does the same job in one atomic call. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * CHANGELOG: add PR number to the startup loading entries Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>