Closed dated closed 4 years ago
Thanks for opening this issue! A maintainer will review this in the next few days and explicitly select labels so you know what's going on.
If no reviewer appears after a week, a reminder will be sent out.
Excuse the crappy framerate, but something a little bit like this, @alexbarnsley?
@dated I like your improvements. But testing here I saw that a scroll bar appears vertically or horizontally and immediately disappears when adding or removing an item.
What OS are you on? On MacOS those didn't appear iirc, I'll see if I can get around that somehow.
My Environment
Gotcha, thanks for the info. I'll try to set the overflow to hidden during the animation. That should in theory get rid of the scrollbars. Kinda hard to confirm on my end though :joy:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
:danstop:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
No no no.
Closing, no longer relevant for 3.0
When adding recipients to a multipayment transaction there is insufficient feedback to the user that the recipient was added correctly.
The first few recipients are obvious, as the user gets to see them added to the list, when the list has reached his max height however the only indication of success is the changed count of items above the list.
As a workaround the list of items could be displayed in reverse, so that a newly added items is added at the top of the list.
To aid this a short animation on the background color or the likes could be added.
The above applies also to the other uses of
InputEditableList
(seed nodes, multisignature registrations, ...)