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.
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".
The Sweep feature needs the 'previous' transactions to build the new
transaction.
This shows a progress-report per-transaction as they are downloaded.
Additionally this splits the incoming electron-X reply into lines before
processing.
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.
We check the first block to figure out if the download is actually the
same one we are about to start, and if it is then Pay will not re-
download the part that is already on disk.
We set the UI to change from 'downloading' state to 'processing' state,
and now we give the UI the processor time to actually show this new
state on the screen before we start that processing step.
seems renaming a file that is mapped is not possible on Android, but
remove is. This code now removes the original static headers after we
get an approval of the downloaded file.
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.
This actually checks the need for downloading more headers,
then decides on which headers to download (from which known checkpoint,
really) and downloads them to a file.
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.
This moves the component out to its own file while fixing some UX
issues.
* It is now always visible for (UI) discovery purposes.
* When we paste when there is no matching text we show negative
feedback.
A peer that has not yet handshaked is now show in this view, giving a
better indication of what is going on on platforms that do not have easy
access to a log file.
tomFlowee