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)
The tx-broadcast was tied completely to a 'payment' object, this is now
more made into individual parts that can be reused outside of the
'payment' usecase.
When we start up we use the last known price information and also fetch
new data.
When the user shows the price details popup before the fetch has
completed, they may be mislead into thinking that they are looking at
current data while they are not.
So this shows a bouncy while we are fetching.
The popup showing details of a certain list-item had the down-side that
the list item we selected was made darker with the rest of the screen,
making it harder to understand the whole info.
This change repeats the clicked item inside the popup in a way that
makes it immediately clear which transaction we are showing details of.
This applies the knowledge learned from mobile to desktop too.
Also set the initially selected import year to 2023 and avoid
long imports for most people.
We use the same header-heights lookup table to show the actual month to
the user on resolve.
The resolve is the fetch of first-use of an address or seed, this
returns a blockheight from elecrum servers only and that isn't very
user-friendly. As such this now fills the comboboxes with the proper
month/year for better understanding.
This makes the language simpler and makes clear that the password field
is related to the import. Second, the name-field is now moved closer to
the big 'start' button and has a more obvious title.
This is the import page, it will certainly be possible for a
user to import a wallet that is older than the headers on their
device. In that case using the headers to resolve the height can't
work.
Circular dependency: Need headers to know which headers to download...
So, we hardcode the historical blockheights here for each month that
the user can select.
Notice that the dates are the first of each month, at the UTC-16
time-line.
The ImportWalletPage now loads the QML provided by the module,
exposed via the metadata of modules.
The module gets just a blockheight property and then will do
"its thing".
This will either instantly close when there is nothing to do
and continue instantly to the actual import.
Or the module will check the server, initiate download and when
all is setup and done THEN close the popup and continue with
the actual import.
tomFlowee