The backend has the historical prices in its database, we ask for it by
timestamp the by default it returns the nearest value. Typically within
24 hours.
But if the database doesn't have the data, or its very inaccurate, this
may casue confusion.
So we now have a new API call that returns zero instead of an inaccurate
historical price. Allowing us to prefer not showing anything over plain
false data.
Since the default option to 'sign' is a self-signed certificate which is
insecure (its in git, absolutely not private), it makes sense to be consistent
and make the default create a test package.
Make it easier on people self-compiling.
We now skip building (and sending) of the bloom filter until we have
finished the initial blockheader sync. (only relevant for newly created
wallets).
Additionally we update the WalletInfo with our inital blockheight as
soon as we know about it.
The downside of having the application singleton be the owner of the
wallets is that the destructor won't get called until after main() has
been completed.
And that means that globals deletion order becomes an issue, which is
messy and should be avoided.
This change splits out the saving and deletion of wallets & p2p layer,
making use of the Qt application object signal to delete wallets just
before the QtGuiApplication object destructs. Which is _inside_ of
main().
The GUI confused 'userowned' and having a list of wallets.
Basically we can just trust the backend 'accounts' list, making
the GUI eaier to understand.
This merges the paymentAmount and effectiveBchAmount methods because they
did 99% the same.
Same with the paymentAmountFiat and effectiveFiatAmount.
This removes the 'effective*' set of properties.
In Qt5 the palette was introduced in the Control object (part of Qt-
Quick-Controls-2).
In Qt6 this property was moved to the superclass 'Item'.
This means that we no longer need to refer to a control when using a
palette, every single thing in QtQuick is an Item, afterall.
Add a property 'fees' to the TransactionInfo class and use it.
This also changes the GUI behavior of the 'sent' field a little.
In the GUI we now show the amount actually meant to arrive on the other
address(es) instead of the amount our wallet became more empty.
This makes a lot of sense if you look at your transaction and compare to
an invoice, now the 'sent' field will match that invoice and it will
match what the receiver actually received.
to reset the payment removes all user set properties, giving you a clean
payment object.
Since the exchange rate is both not user-set and also not something that
is expected to change between one payment and the next, it is now no
longer cleared on reset().
tomFlowee