- Make sure we always set the proper wallet on create, this would
fail on the very first after the initial wallet being created.
- Don't allow marking the initial wallet as archived in the UI
as that is a non-reversible action. The app will do it automatically
after a couple of weeks.
This adds a context menu to open the transaction in the blockchair
explorer.
We also show a visual feedback on copying the txid.
And we update the blocks past to be number of confirmations and avoid
any confusion.
This stores the time of a transaction in the store of the wallet, and
indeed sets it when it is added to the wallet first time.
For instance when we create it or when the tx is first sent to us at
initial broadcast.
We add some logic to the model in order to put a bit more effort into
finding times of a transaction that did not get mined and (before this
code) did not get its time of creation set. Mostly this is about
rejected transactions. And there we guestimate the time instead.
This specifically allows pasting and scanning of bitcoincash addresses
without the 'bitcoincash' prefix.
Additionally this cleans up the QRScanner API a little and merges two
methods.
Last, at popular request, this makes showing the address on the
confirmation screen default to be on.
This allows people to actually verify the address they pay to.
Except when paying to a BIP70 payment because that is practically
speaking a system that avoids talking about addresses in the first
place. No point in trying to verify the actual address THERE.
In the case where there is no specific input needed, because the amounts
were all specified, we still need to set the focus to the page because
otherwise 'back' / 'esc' don't behave correctly.
Pressing 'Escape' or (android) back button is now more logical.
Closing the menu is new, going back to the 'main' tab as well.
This also fixes some odd behavior when using the back button while the
camera is active.
And last, when there is nothing more to back out of, on Android we end
up closing the application. This is what people expect on that platform.
To swipe from the left edge now is limited to only 50 'pixels'
instead of half the width.
Additionally, don't allow interaction while the app pin-screen
is showing.
This calls Java code on Android through the Qt JNI bridge
in order to learn the phone-wide setting of dark-theme.
For new installs this will now follow the phone setting by default.
Add GuiSettings: dark mode option.
In addition:
- Made it work with latest commit to Flowee/thehub/#5.
- Works better now when decrypting the wallet (accountInfo.isElectrum property
should not be CONSTANT but instead notify on change)
- Made the actual wallet seed phrase type get saved to the wallet rather
than a bool. This type comes from enum HDMasterKey::MnemonicType in
thehub libs.
The CPP now does more of the (heavy) lifting and the UI layer can
ignore
most of the details with regards to there being digits behind the
separator for fiat at all.
The internal change is that the fiat based values are always processed
in cents, even if the cents are not displayed. This solves incorrect
display and generally removes special cases.
One surprise was that the main usecase of pasting is one where the user
activates another app to go and copy data in order to come back to paste
it.
And the Qt clipboard didn't manage to get any notification of clipboard
changes. Even copying data on becoming active had no effect.
So now I just show the paste optimistically when the user comes back
from another screen, assuming the main reason for that was to copy.
This makes available a clipboard helper component in QML.
Based on filters we then can make the 'paste' button visible and
only allow pasting stuff that is remotely useful.
This then also adds a 'paste' button to the transaction-building
module, the 'destination' screen.
We test on desktop, but this component with an actual mouse stops me
from clicking on the "Home" button in the test env. So lets just turn
that off and make the slide-to-open only happen on production devices.
For desktop we now properly support starting a payment when
the user clicks on a bitcoincash link in a browser.
For Android the activation logic _should_ work, except that the
Android specific way has yet to be tied to our app.
Squash of 12 commits, this makes the UX actually useful and
we detect errors and show errors and warnings to the user.
This also adds an 'editable' bool to OutputDetail in order to
disable editing of a payment request address.
Additionally, this introduces the ability for a Payment to carry
a raw script instead of an address. So op-return or more complex
payment requests will be sent just fine.
Fun fact is that our broadcast is INV/SendData, which is two
roundtrips and thus slow, which is needed to be sure we get proper
rejection messages.
The sending of the transaction via BIP70 causes the network to
already know about the tx because the server we send it to has
likely much better Internet than we do.
So confirmation from the payment provider is used to show success
instead of the normal way.
The PaymentProtcol class now handles the pasting of a payment uri,
like bip21.
Additionally this adds the feature where we pass in the payment uri on
the commandline which then results in an auto-opened payment screen.
The QR scan page now also allows showing the destination address
while the number keypad is up, being smarter with the layout of
the various lines in order to fit the important info on screen.
Additionally we require the user to first enable the 'edit amount'
option before we make available the option to 'send all'.
People that only use one hand will no longer need to use the other to
reach the button at the top for the menu.
Instead we now allow a swipe in the bottom left corner, swiping to the
right will make the menu open.
tomFlowee
Calin Culianu