-
-
Notifications
You must be signed in to change notification settings - Fork 665
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI tweaks for ETH contract flow #4346
base: main
Are you sure you want to change the base?
Conversation
|
|
28d80a5
to
3374fa4
Compare
4ee434b
to
29da869
Compare
aff8fa9
to
962a2e7
Compare
3aef883
to
fc54ad1
Compare
962a2e7
to
dbaac78
Compare
f4bbfd8
to
ee1642a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while we're at this, can you remove text_mono
and info
(and possibly even hold
) from confirm_blob
?
// we would need to account for that and we could not use a constant. | ||
let mut menu_choices = VerticalMenu::empty().danger( | ||
theme::ICON_CANCEL, | ||
verb_cancel.unwrap_or(TR::buttons__cancel.into()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not make verb_cancel
non-Optional and prefill this string at construction time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what is the benefit. It would just move the check / unwrap at a higher level, most probably in ConfirmBlobParams
- because that one can have it missing. Let's say I also set it to TR::buttons__cancel
in ConfirmBlobParams
, I would still need to make the check in new_confirm_action
. Unless I make it non-optional there too and set a default in uPy... Either way, the default would have to be somewhere, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, yes, we kinda want to work with non-Options from as early as possible. If None
here doesn't have a special meaning, it should be unwrapped at the earliest convenient place, which, yes, would be new_confirm_action
.
No reason for a code tree this deep to be aware that the caller somewhere six stack frames out was too lazy to specify the value explicitly.
It may make sense to accept a None value from Python, because that's (a) an API boundary and (b) Python doesn't make it convenient to specify translated values as default arguments -- you can't say def confirm(verb: str = TR.some__verb)
because then it does not get updated when you change a translation.
But that's a property of the API, that it allows you to not specify a verb. Not a property of the implementation, where we always require a string to work with (unless we don't?), just that we have a default value for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK: fc0bb63
I think I understand your point, and it can be seen like this too, indeed.
I was seeing it from the other angle - as much as possible instantiate these "string bearing structs" like ConfirmBlobParams
and ConfirmActionMenuStrings
(maybe I should rename it to ConfirmActionMenuParams
while at it...) with no parameters, have everything default to None, and do with_XXX
only when "XXX" needs to be changed to something other than the default. Otherwise the struct would carry the None all the way to the very end, where the default would be used. I think @obrusvit 's recent changes also went in this direction - dropping as many parameters from ConfirmBlobParams::new
and moving them to .with_XXX
.
Of course, the two ways are not mutually exclusive, which is what I tried to do at fc0bb6 - not sure whether you guys like it - but basically ConfirmBlobParams::new
still means you want to go with defaults, but the default verb_cancel
is set to TR::buttons__cancel.into()
in the ctor rather than to None
- so this "params bearing struct" carries the concrete default around. Maybe if this is what you meant, then I should just replace the rest of the strings in ConfirmBlobParams
in the same way... I think I like it...
The disadvantage is of course that multiple instantiations of ConfirmBlobParams
around multiple API functions have to unwrap_or
if they want to do a .with_verb_cancel
(in order to let the uPy code customize the verb. OOOOR, I could make with_verb_cancel
accept an Option and have it set the default in case it received None
- but I don't know why, that looks less appealing to me (even though the opposite leads to duplication of the default value).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe if this is what you meant, then I should just replace the rest of the strings in
ConfirmBlobParams
in the same way... I think I like it...
yes, this is what I have in mind
multiple instantiations of ConfirmBlobParams around multiple API functions have to unwrap_or if they want to do a .with_verb_cancel (in order to let the uPy code customize the verb. OOOOR, I could make with_verb_cancel accept an Option and have it set the default in case it received None - but I don't know why, that looks less appealing to me (even though the opposite leads to duplication of the default value).
wondering about this .. would it make sense to construct ConfirmBlobParams
and friends by passing the micropython options -- gated by #[feature(micropython)]
of course?
wdyt @obrusvit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @obrusvit 's recent changes also went in this direction - dropping as many parameters from ConfirmBlobParams::new and moving them to .with_XXX.
My motivation was not to drop as may params as possible from ConfirmBlobParams::new
but to keep only those which are used by all callers. There were 7 params and 4 calls were setting the last 4 to None
/False
Hence I reduced the new
params count to 3 and put the rest to with_xyz
builder methods.
wondering about this .. would it make sense to construct ConfirmBlobParams and friends by passing the micropython options -- gated by #[feature(micropython)] of course?
wdyt @obrusvit
Do you mean constructing ConfirmBlobParams
with (n_args, args, kwargs)
. Hmmm, I don't like it very much. IMO, ConfirmBlobParams
should be deeper in the UI code with rusty-types.
It's true that initially the trait UiFeaturesFirmware
(or whatever the name will be) will be riddled with micropython stuff, but mostly just Obj
, which should be replaced later on.
let content_menu = Frame::left_aligned("".into(), menu_choices) | ||
.with_cancel_button() | ||
.with_swipe(Direction::Right, SwipeSettings::immediate()); | ||
if has_info { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if has_info { | |
if let Some(verb_info) = verb_info { |
assuming (again, dtto) that verb_info
default value is prefilled at Menu
construction time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, something like this I guess: 1eff1d8
Now new_confirm_blob
looks strange, but once I remove the info
parameter completely, it will look great - basically the decision on whether to show info or not is done by passing Some
or None
in verb_info
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turned out slightly different actually, but anyway, we'll discuss this in the next PR, which does not cleanup on confirm_blob
.
313f806
to
69d448f
Compare
[no changelog]
[no changelog]
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. [no changelog]
[no changelog]
[no changelog]
[no changelog]
[no changelog]
ee1642a
to
d2cc6c0
Compare
b0a3a4a
to
fc0bb63
Compare
I'll do that in the next PR if you don't mind, together with cleanup of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some points to discuss.
@@ -150,7 +150,7 @@ impl<'a> Component for ShareWords<'a> { | |||
} | |||
|
|||
impl<'a> Paginate for ShareWords<'a> { | |||
fn page_count(&mut self) -> usize { | |||
fn page_count(&self) -> usize { | |||
// Not defining the logic here, as we do not want it to be `&mut`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove obsolete commentary since the param is not mut
anymore.
@@ -318,11 +337,13 @@ pub fn new_confirm_action_simple<T: Component + Paginate + MaybeTrace + 'static> | |||
strings: ConfirmActionStrings, | |||
hold: bool, | |||
page_limit: Option<usize>, | |||
show_page_counter: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could probably be also named page_counter
just like in `ConfirmBlobParams.
@@ -191,6 +194,22 @@ fn new_confirm_action_uni<T: Component + MaybeTrace + 'static>( | |||
.with_menu_button() | |||
.with_footer(TR::instructions__swipe_up.into(), None); | |||
|
|||
if show_page_counter { | |||
fn footer_update_fn<T: Component + Paginate>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think defining the fn
inside this if
has no benefit - it's not a Fn
object which would not be created if show_page_counter
was false
. I would put it outside as a free-standing function and would just do
if show_page_counter {
content_intro = content_intro
.with_footer_counter(TR::instructions__swipe_up.into())
.register_footer_update_fn(footer_update_fn::<T>);
}
Intro, | ||
Menu, | ||
Confirm, | ||
enum ConfirmAction { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised this is even needed - no menu means no way to "Cancel"
// we would need to account for that and we could not use a constant. | ||
let mut menu_choices = VerticalMenu::empty().danger( | ||
theme::ICON_CANCEL, | ||
verb_cancel.unwrap_or(TR::buttons__cancel.into()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @obrusvit 's recent changes also went in this direction - dropping as many parameters from ConfirmBlobParams::new and moving them to .with_XXX.
My motivation was not to drop as may params as possible from ConfirmBlobParams::new
but to keep only those which are used by all callers. There were 7 params and 4 calls were setting the last 4 to None
/False
Hence I reduced the new
params count to 3 and put the rest to with_xyz
builder methods.
wondering about this .. would it make sense to construct ConfirmBlobParams and friends by passing the micropython options -- gated by #[feature(micropython)] of course?
wdyt @obrusvit
Do you mean constructing ConfirmBlobParams
with (n_args, args, kwargs)
. Hmmm, I don't like it very much. IMO, ConfirmBlobParams
should be deeper in the UI code with rusty-types.
It's true that initially the trait UiFeaturesFirmware
(or whatever the name will be) will be riddled with micropython stuff, but mostly just Obj
, which should be replaced later on.
@@ -262,9 +269,19 @@ impl ConfirmBlobParams { | |||
} | |||
.into_paragraphs(); | |||
|
|||
let confirm_extra = if self.cancel { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so cancel
param means it's just "Cancel" in the menu but if cancel == false
then the menu contains and "Cancel"?
content_area = content_area.inset(Insets::top(theme::SPACING)); | ||
content_area = content_area | ||
.inset(Insets::top(theme::SPACING)) | ||
.inset(Insets::top(margin as i16)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes the real margin now SPACING + margin
. It's quite confusing but probably fine.
@@ -329,6 +317,44 @@ extern "C" fn new_confirm_blob(n_args: usize, args: *const Obj, kwargs: *mut Map | |||
unsafe { util::try_with_args_and_kwargs(n_args, args, kwargs, block) } | |||
} | |||
|
|||
extern "C" fn new_confirm_blob_intro(n_args: usize, args: *const Obj, kwargs: *mut Map) -> Obj { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't love it as it creates mercury
specific layout. But probably fine for now.
has_info: bool, | ||
verb_info: Option<TString<'static>>, | ||
} | ||
|
||
impl ConfirmActionMenuStrings { | ||
pub fn new() -> Self { | ||
Self { | ||
verb_cancel: None, | ||
verb_cancel: TR::buttons__cancel.into(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we can introduce:
const VERB_CANCE_DEFAULT: TranslatedString = TR::buttions__cancel`;
and use it on the unwrap_or
calls?
This is a continuation of #4343, addressing the UI side of #4302.