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.
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.
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 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.
The isSingleAccount property controls if the UI is simple or more
complex.
The single account setup doesn't show you that you have any concept on
differnt accounts at all. No account chooser etc.
On Desktop, however, we choose to always show the archived wallets
anyway. Even though its not in-your-face. Which makes the behavior
between those UIs slightly different.
The addition of the limitedArchiveView property is meant to
facilitate that.
Pressing 'Escape' or (android) back button is now more logical.
Closing the menu is new, going back to the 'main' tab as well.
This also fixes some odd behavior when using the back button while the
camera is active.
And last, when there is nothing more to back out of, on Android we end
up closing the application. This is what people expect on that platform.
This calls Java code on Android through the Qt JNI bridge
in order to learn the phone-wide setting of dark-theme.
For new installs this will now follow the phone setting by default.
Add GuiSettings: dark mode option.
The PaymentProtcol class now handles the pasting of a payment uri,
like bip21.
Additionally this adds the feature where we pass in the payment uri on
the commandline which then results in an auto-opened payment screen.
The Android design is that you can "close" the app while it is not
actually killed. It stays frozen but in the background.
This makes Pay check the clock on 'wake up' and if 10 minutes has passed
it will lock again.
We already allowed individual wallets to get PIN-to-Open/PIN-to-Pay
but that is too advanced for most users. Not to mention that encrypted
private keys means a slower payment process and certain types of
features become impossible. Like auto-invoicing (incasso).
The gap, for mobile, is a simple not-encrypting password on startup
of the app which is likely what 80% of the privacy / security minded
people on mibile will be more than happy with.
This adds this mode and additionally streamlines the encrypted modes
of wallets.
The GUI confused 'userowned' and having a list of wallets.
Basically we can just trust the backend 'accounts' list, making
the GUI eaier to understand.
For all times we start with a completely empty Flowee Pay, show a
landing page which guides the user to create a new wallet or deposit
funds into the default wallet.
This adds a prettty cutout screen and better feedback on the camera view
popping up.
We also make visible the scan overlay instantly, hiding out any other UI
that is hidden beneath it.
We correctly handle various odd issues with Qt / Android.
- the permissions request (QFuture) returned in a different thread, we
now move back to the main thread before doing any calls on the
multimedia objects.
- The popping up of the android permissions requestor actually makes the
app think its being made inactive. Now we no longer cancel the QR scan
request in such cases.
After working on android and the qtmultimedia library for a week,
I have a much better understanding of what works and what doesn't.
The resulting design is thus presented. We will have one
CameraController class which refers to one overlay panel in QML
and in different places in the GUI objects based on QRScanner
can be created to initiate a scan.
This additionally moves the actual scanning out of the GUI thread
since blocking that is a no-no.
Now to move towards actually supporting scanning usecases.
As most of our app will be based on Pages pushed to the stack,
a simple structure to move focus forcefully to the new child
has been added.
Children would basically only need to mark the first item as
taking focus.
This approach works great for touch events, not so wonderful for mouse
events as it stops me being able to swipe on lists with the mouse.
So disable this on platforms that don't use touch primarily.
We now hardcode the style and I needed to override the Label
in order to explicitly use the palette from the mainWindow. Not
sure why the one on Android behaved different than on Linux.
On the mainscreen have some big tab-buttons for the main features
then we have a menu overlay which can hold various other screens
and features. Those screens will be placed on top of the main
tabbed screen using a stack-view which is common on touch-interfaces.
tomFlowee