This separates it into two objects in order to make thead-safety easy
using Qt's signal/slot mechanism.
Additionally this removes magic timeout numbers and simply starts a
timer to check for changes and emit a signal if the status actually
needs updating.
Testing also shows that QML calls the getter a LOT, so I also moved the
broadcastStatus to be buffered and just return that on the call.
This incidentally also simplifies the code, double win.
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.
This splits the latter class into an abstract baseclass that finds a
server and handshakes with it called ElectronXClient
and then as a subclass the import handler handling doing what it always
did.
The Payment specific methods paymentAmount and paymentAmountFiat are now
made to return the data from the first output and no longer required
there to be exactly one.
This allows these methods to still give useful info in the case of
payment protocol based creation of more complex payment objects.
This takes the concept added some 5 years ago to Electron-Cash and adds
this to Flowee Pay as well.
In a nutshell, it allows a bip21 style payment request to include a
'comment' with the argument op_return_raw
This comment is expected to be a hex-encoded data payload that then will
be added as a single output to the transaction we build to fullfill the
payment request.
As a natural consequence of how uri's work, adding the argument multiple
times will cause multiple outputs to be generated. We check that this
does not exceed the expected max sizing for op-return.
The Tx::Iterator no longer returns the token data as part of the
output-script, but instead sees them as separate tags.
This removes most of the code here, and makes future deeper
support of cashtokens much easier.
THese two countries use the Euro, but unline most Euro
countries they put the currency indicator behind the
numbers.
With Slovenia even avoiding the euro-sign in most places.
This adds the specialization based on the phone set country.
this changes the call for historicalPrice() to now take the (int based)
timestamp as a ref and we change that to the actually found timestamp
upon success.
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.
This changes us to no longer use the exception to find out the
time is before the checkpoint, but instead checks directly.
This was needed since upstream changed to no longer throw since that's
still a bad practice in C++
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.
As we start to ship headers based on a checkpoint, the earlier code
to overwrite an existing static-headers file when the new delivable
is larger is no longer useful.
This is because just being larger doesn't mean the checkpoint it
extends will stay the same.
We simply won't overwrite a static headers file anymore.
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.
Plugins can be plugged into the main menu and the send menu already,
this adds the ability for a (section of a) plugin to be loaded as
custom component in the main app, among others.
tomFlowee