This side-steps a double-import problem that is triggered when we
perform an unimport in a particularly unfortunate order. (don't ask)
The root cause of the problem still exists: we can get into a situation
where a live recovery_homescreen is running from an unimported module,
meaning that any new import of anything from the recovery_device
namespace will _also_ be a double-import. We don't have a fix for that
situation yet, so instead we avoid this particular local import, which
would cause homescreen_dialog to have its own copy of the `recover`
module.
In case the main workflow is restarting after a `DebugLinkDecision`,
sending the response of `DebugLinkGetState` may get interrupted.
We are making the state fetching explicit, in order to avoid the
"restart" race condition (as described in #4401).
Following the above change, text-based layout recording is removed.
[no changelog]
- application layer should not deal with fonts at all
- distinction between MONO and others is preserved by bool argument in
`should_show_more` interpreted as `is_data`
[no changelog]
- seems that keyboard LayoutObj was not properly deallocated resulting
in MemoryError. Fix by calling the dunder `del` method explicitly fixes
the issue
- the problem was on Model T (Bolt), but applying it for all layouts to
prevent similar problem
- follow-up on 862c987779
- layout_bolt stays the same
- layout_samson -> layout_caesar
- layout_quicksilver -> layout_delizia
- use super for importing rust modules in layout code
[no changelog]
- UI layouts name changes:
- model_tt -> layout_bolt
- model_tr -> layout_samson
- model_mercury -> layout_quicksilver
- rust features `model_xyz` freed for different use, now it's
`layout_xyz`
- input_flow function names are based on UI layout and not internal
model name (i.e. quicksilver instead of t3t1)
- directory names and commentary changed accordingly
[no changelog]
For reasons unknown, a previous homescreen layout can sometimes survive
a GC cycle in main's unimport loop. Two homescreen layouts can't exist
simultaneously, so creating a new one would fail.
It _seems_ that after restarting the session, the homescreen object
still exists but is not reachable anymore, so a second GC cycle properly
disposes of it.
So what we do is simply catch the possible MemoryError, invoke GC
explicitly, and try again.
- keyboards
- standalone functions
- disable_animations
- check_homescreen_format
- confirm_action
- selectors
- confirm_firmware_update
- show_homescreen/lockscreen
- confirm_homescreen
- confirm_homescreen of mercury changed according to Figma
- set_brightness
- show_wait_text
- show_progress
- request_number
- show_checklist
- show_mismatch
- confirm_reset
- tutorial
- confirm_coinjoin
- confirm_modify_output/fee
- show_group_share_success
- show_remaining_shares
- show_success/warning/error/danger
- show_simple
- continue_recovery
- confirm_recovery of model_t and model_r merged with
flow_continue_recovery of mercury into a continue_recovery_homepage
trait function, parameters renamed to be more descriptive
- show_share_words moved and refactored
- model_t version was moved from using plain Paragraph to a dedicated
component `ShareWords` so that it's consistent with other models. This
allowed to move formatting to Rust and allowed the trait function to
have `words` parameter of type `Vec<TString, 33>`
- model_r ShareWords::render slightly refactored to be consistent with
the new model_t version
- mercury uses a unique version. The reason is that mercury SwipeFlow
contains also the initial screen with instructions and prompt screen at
the end.
- confirm_with_info
- show_info_with_cancel
- confirm_blob
- confirm_value
- confirm_properties
- confirm_more
- confirm_address
- prompt_backub
- confirm_emphasized
- show_address_details
- confirm_summary
- TR removed:
- confirm_output_address and confirm_output_amount replaced with
confirm_blob. UI diff is minimal.
- confirm_joint_total, replaced a TR-specific function with a generic
`confirm_properties` with no UI changes
- confirm_multiple_pages_texts
- the function is TR specific and is used only in confirm_set_new_pin,
it would be better to use something different
- remaining mercury flows with no counterpart
- confirm_blob_intro
- flow_confirm_set_new_pin
- flow_confirm_output
- flow_get_address
[no changelog]
- the commit introduces a trait defining high level UI building blocks,
common for all models.
- trezorui_api module exposes these functions to MicroPython world.
- `show_info` is implemented as a first function.
[no changelog]
- the new module is the place for type definitions of the interface
between rust and micropython world.
- the new module will replace `trezorui2` with `trezorui_api`
[no changelog]
This makes it possible to run HW tests on the T3T1 where animations mess
things up. It also speeds up HW tests on other models slightly.
export TREZOR_DISABLE_ANIMATION=0 to build a debug firmware with
animations enabled
This commit adds a margin and footer description to the first page of
the paginated blobs to be confirmed on Mercury. It also extracts the
part of confirm_blob that deals with the first page to a separate
function in order to keep confirm_blob simple.
Commit c300576d6c introduced
`confirm_blob_with_optional_pagination` which proved to be unpopular and
impractical. This commit brings back the old behaviour of having the
`ask_pagination` parameter on `confirm_blob`. It also reverts back to
using the old way of paginating `confirm_blob` on model R, which the
aforementioned commit ignored and re-implemented from scratch.
[no changelog]
Commit c300576d6c introduced the
`default_cancel` parameter to `show_warning` and `confirm_blob` rather
using the already existing `flow_warning_hi_prio` which was doing the
same thing. This commit reverts all the nonsense.
[no changelog]
This was necessary for hooking display.refresh() with the old UI toolkit.
With the new one, we explicitly refresh the display after every paint, so
implicit after-step refresh seems no longer necessary.
otherwise if _handle_single_message raises an exception (which is
fortunately not something that should generally happen), the
finally-block would fail on "referenced before assignment"
