Initial Template for Request Payment page #435
Conversation
|
The piece I'm most concerned about this form is the Amount input field and how to properly sanitize and convert the field. The current object backing it doesnt quite feel right but I am limited by the inability to extend the actual TextInput class. |
johnny9
changed the title
| { | ||
| QString result = text; | ||
|
|
||
| // Remove any invalid characters |
There was a problem hiding this comment.
Is this the right thing to do?
QT gui simply refuses to paste when there are invalid characters.
yeah there are a couple weird things:
|
This control is primarily used in wallet forms where the user is expected to input values for sending or receiving transactions. It contains a Label describing the input as well as a TextInput where the actual string is entered. A Icon is also available on the right side of the component for extra actions.
The copy icon will be used to initiate a copy to clipboard when it is clicked.
The flip-veritcal icon is primarily used when flipping the units displayed when clicked
The pending icon will be used to show the status of transactions
johnny9
force-pushed
the
request-payment-form
branch
from
1b869eb to
e642461
Compare
BitcoinAmount is a helper object can be used to manage inputs in sats or btc.
This page contains the form for the user to fill out to create a payment request.
This page contains the details of a payment request. It is pushed onto the RequestPayment page's stack after the user has clicke don Continue.
johnny9
force-pushed
the
request-payment-form
branch
from
e642461 to
adff8f2
Compare
|
From from 1b869eb to adff8f
|
|
Looking good. I know we talked about this before, that the basic concept of the receive page has changed a bit. Away from the two separate pages, and towards creating the QR code directly on the page. Just realized I already implemented this in the web prototype here (note the differences in responsive layouts). The amount input logic, which you bring up, is not properly implemented in the web prototype. There definitely has to be some sanitation. Something to look out for is that when I type In a web prototype update I am working on, I am tying the unit toggle to the application setting. So when you switch the unit in the amount input, the wallet balance display in the top left also changes. Wonder if that is intuitive or not. What do you think? In the send page, that unit setting should at least live on a user flow level. So when you toggle, the unit in the amount input, but also the fee selector changes, as well as the unit in the review screen. Small thing about the input and amount fields is that I can enter unlimited characters (and emoji). Should probs be restricted in some way. |
I will remove the confirmation page and get the request page in alignment with the latest. I won't be able to get QR codes functioning in this PR as that will have to be a follow up once the requests are working end-to-end.
I'll double check this. I've made some improvements with the amount but I havent tried emojis |
|
Updated the form to be a single page. Does not include QR code generation, separation of address text into individual items with their own background, or the copy tooltip. I'd prefer to add these details afterwards. |
|
Looks great. I know you want to exclude various interaction details and handle those in follow-ups, so I won't comment on those. Just one question about the layout. Does this already include the mobile one where the QR code is inline and the buttons are static at the bottom? |
These commits introduce the Request Payment flow. This view is available under the "Receive" tab on the Desktop Wallets main navigation view.
The Request Payment form itself currently only includes fields currently supported by the Qt wallet (label, message, and amount). Follow up PR will add support for local notes.
The Amount field in the Request form takes only valid Satoshi/Bitcoin amounts and supports flipping the units with the associated button toggle.
When the Continue button is pressed the Request Confirmation page gets pushed to the stack will eventually reflect the fields inputted in the previous form backed by the output of the WalletModel result. In its current implemention it just has statically defined properties to check the visual layout. The page also contains an address field with the copy icon that can be used to move the address into your clipboard.
Ubuntu screenshots
