This upgrades us to no longer use the expected block height based
on current time, but instead uses the certainty we get from asking
various peers for their view of the world.
Now when we are certain that we're at the same tip as the rest of
the world, we can safely hide the 'up to date' text and make the UX
again a little bit simpler.
On Android an app can ship with (static) shortcuts. We use this feature
to allow the user to create a new icon which still starts Flowee Pay,
but it instantly opens the payment screen on the QR scanner.
The vast vast majority of wallets imported will not have a password. So
we de-prioritize that and make the user aware of the password field
should they check the contents without one.
This moves the 'wallet name' again to the top for all types as the most
observed mistake is that people type a wallet-name in the password field
and then are confused why there is nothing there. (and additionally
annoyed that the name of the wallet is auto-generated).
Other fixes includes spacing and alignment.
Keyboard focus on desktop.
The idea of using Flowee Pay to open a payment screen, or a sweep
screen, was so far married to the executable lifetime due to it being
passed as a command line argument.
This does not reflect reality, on neither desktop nor on mobile as
multi-tasking is possible and we should allow that.
As a result the new object "Intent" has been introduced with the
usecase specific properties. Setting those properties at any time
during the lifetime of the app now pushes the correct page to the
stack on mobile. Desktop is in need of more love in this department.
This allows a user to click on a link in a browser with the bch-wif
scheme and we'll handle that with a sweep page on startup.
To avoid this being just-another-special case we introduce a new
module (read: plugin) concept that is a Start-screen type.
The idea is that we can have a generic handling of this type in
various parts of the app without it being specifically about the
wif handling.
Notice that it doesn't matter if the user has the module enabled,
which just operates the display of the menu option to start it manually.
On the mobile client this allows the user to check per wallet which kind
of transactions to show or hide.
We allow selection of send/receive/both.
We allow the hiding of cash-fusion transactions.
To amke it more clear that the QR scanning screen also always allows
clipboard input, make the paste button always be there and just make
it have a constrasting background when the clipboard content is
acceptable.
We also add a 'shake' feedback when the paste doesn't work, and naturall
the paste button is available for clicking even if it doesn't look
'enabled' which will then just result in a shake and 'failed' feedback.
As we get more modules it turns out that the 'send' tab as originally
envisioned isn't really representative of how we're evolving.
Various items end up being about doing 'stuff' in general. Including
creating a transaction to receive. Only in a very loose way can we
say those are 'send' items.
So, without actually any user-visible changes, this renames the
enum in the module manager and module-section to make it about the
more accurate "action menu".
This adds the backend code and the buttons that allow deletion of a
wallet.
Formerly you could archive a wallet and thus remove it from view,
at popular request an archived wallet now gets a button in the
wallets overview to delete the actual wallet completely.
This indeed also removes the files from disk, making it unrecoverable.
Additionally, an actually more complex feature, this allows an existing
wallet to have its history removed and start a re-scan to re-download
all transactions and build the balance.
This is useful for debugging or for recovering from buggy code we
probably had in older versions. (nobody is perfect all the time)
tomFlowee