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 removes the support for older than qt65 for mobile.
Qt65 was released April 2023, making the code we now release not
needed anymore. End of 2024, and us moving to 6.8 feels like we're
safe in removing it.
This takes the NotificationManager and splits it into multiple
compile units based on the backend that is available.
The 'dbus' was the only one available so far (which serves
kde/gnome desktops) and this is moved to its own file.
This adds android support as well, but so far only for block
notifications (when a new block is mined).
This reverts a broken Qt patch wrt translation selection. See QTBUG-131894
This removes various Qt features from the build that we don't need
in order to keep the library size down.
The qtdeclarative module went from 4285 ninja tasks to 2387, or for the
android buld from 4117 to 2251.
This upgrades us to no longer use the expected block height based
on current time, but instead uses the certainty we get from asking
various peers for their view of the world.
Now when we are certain that we're at the same tip as the rest of
the world, we can safely hide the 'up to date' text and make the UX
again a little bit simpler.
CMake details for finding boost have been shipped for years inside
of boost, this makes cmake use that upsteam info to configure boost
and avoids problems when a newer boost than cmake is found.
On Android an app can ship with (static) shortcuts. We use this feature
to allow the user to create a new icon which still starts Flowee Pay,
but it instantly opens the payment screen on the QR scanner.
The vast vast majority of wallets imported will not have a password. So
we de-prioritize that and make the user aware of the password field
should they check the contents without one.
This moves the 'wallet name' again to the top for all types as the most
observed mistake is that people type a wallet-name in the password field
and then are confused why there is nothing there. (and additionally
annoyed that the name of the wallet is auto-generated).
Other fixes includes spacing and alignment.
Keyboard focus on desktop.
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.