This shows the amount of coins stored on a single address, which we
sweep in one transction by default for privacy reasons.
This adds the ability of the user to specify how many outputs a single
transaction should have when we create it.
Instead of pre-allocation, this moves it to just before we actually
broadcast.
This solves a possible failure of detecting target funds in case the
number of transactions is larger than the gap and the user sends only
one or two of the later once instead of all.
When a transaction has been created by the plugin, this stores it also
on our UI classes and forwards the broadcast status for the front end
to use in some animation.
This section type means that the module will have it's icon shown in
the 'Explore' tab always, it can not be disabled by users and as such
it just becomes an overflow of the main app avoiding worry about a
module not being found.
This is probably a good first milestone, the UX is pretty decent
and the wanted functionality is there.
Various todo's are still there which mostly of the cleanup type.
In the send-sweep module as well as in the PayWithQR this removes
the UserIntent handling and instead moves that to the main.qml
exclusively.
Additionally in the send-sweep module the camera work is split
into its own page, like in the other parts of the app. This helps
us avoiding hacks when we want the main functionality without the
camera.
This is the last of the series of reworks, we should have all
former functionality working again.
Continuing the 'rework send page' series.
This moves stuff that had no business being on the "Send" page to
live on a new tab instead. Prime example was the 'sweep' module
that creates a transaction we send, but to ourselves. So it's far
fetched that it fits in 'send'.
This reverts commit 9f69241bbb.
Reason for revert is that instead of renaming the send, we're now
creating a new tab instead. So we'll keep "Send" and add a new one
as well.
The initial design has done well for over 2 years, but problems
are starting to show.
This does a bit of cleanup in the UX and many cleanups in the
underlying architecture that were the result of those UX choices.
We remove the clipboard (paste) concept from the camera pipeline
completely and simply make it a new top-level button "paste" on the
send page. This helps discovery AND helps architecture!
The both workflows now also become 2 stage affairs, when the button
is pressed we open a page that does the scanning or pasting and then
introspects the actual data in order to redirect to the right page.
This means that we auto-detect if the scanned item is an address or
a private key or whatever, and handle it appropriately without needing
any user interaction.
This fixes the issue that the "sweep from browser" would consume the
property before the QR scanner had time to decide it should skip
scanning due to that property existing.
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.
tomFlowee