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