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.
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().
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.
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().
For the payment object it now is possible to insta-commit to changes and
as such always prepare a transaction ready to be sent with the latest of
the settings.
This is enabled with a boolean property 'autoPrepare' (default off).
The Payment::paymentAmount() method is for the usecase where the GUI
doesn't care about the input/output details.
Its unused in the desktop GUI.
This method now takes into account the concept of 'max', returning the
full wallet amount if its set.
Provide a QML point where a different locale can be given for a different
currency. This then swaps out the historical file to the new one and
fetches from the online stream in that currency.
Instead of recalculating every single block, we now use the existing
locking of UTXOs feature to lock coinbase outputs to a certain
maturation height.
This is the traditional trade-off where we store some more data to
avoid work in the common codepath.
We now show the estimated tip until the headers chain has been synched.
This follows p2pnet listener interfaces changes.
This uses the nicer interfaces setup to make available for FloweePay
the signal that we have reached the tip of the headerChain
After introduction of pay_mobile, we now have a static lib of all
classes that get linked to the unit tests, as such we can remove
optimizations that tried to keep the set of files to compile in tests
smaller.
This is a bit of a violation of layers, as a result of the ListView not
having any way to do this. Even in a hacky way.
The usecase is that we need to stop the listview scrolling and showing
new items that are being inserted at the top in some cases.
Specifically when the user taps on a single transaction in order to get
more information about it, at that point the popup should be displayed
next to the item we tapped on and that item should not move due to
there being new transactions found.
The freezeModel property accomplishes that by simply not telling the
model new data has been found as long as the property is true.
Afterwards all the updates that have accumulate are flushed.
This makes sure that after initial setup of the wallet we save the
private data and the wallet that was not owned by the user is stored as
such.
On Android the destructor often is not properly called, which leads to
us not saving this on shutdown and that showed this bug.
Move to the next eventloop event the usage of the camera (finding out
resolutions etc) which looks to help stability.
Also remove the init-on-startup again, which had the nasty side-effect of
turning on the camera for a very brief time due to some Qt bug that
ignores the 'active' boolean on the camera object.
QtMultimedia on Linux has the nasty bug that stopping the camera doens't
allow us to start it afterwards. So for now, while Qt is still buggy, lets
simply not stop it.
Notice that this is Linux only, where I expect this class to have very low
usage.
Android doesn't have this specific issue.
On mobile its more visible that it takes a couple of seconds to fetch
the price from the network. The result is that no prices are visible on
unconfirmed transactions and wallet balances for that time.
This instead uses the last known correct price from the historical
database as the price, so in that couple of seconds we are showing the
mostly correct data instead of no data.
When the price feed comes in, all values on screen get automatically
updated.
tomFlowee