For Page inhering screens (BroadcastFeedback/UnlockApplication)
This changes the Page.hideHeader to now act like a full screen,
removing all insets from the Page object when enabled.
The insets are then re-added on the child pages, but
without affecting the background fields, so they cover the insets.
UnlockApplication is a simply full screen widget, we added the
insets to it too.
The checkFinished slot is not executed based on a timer instead of based
on progress.
This avoids problems when the downloads were all done but we were still
waiting for something. Now we notice that all is done since we keep
calling the slot because it is on a timer.
The net log is useful without the quick deploy and indeed the quick deploy
will create problems on first install, so according to the law of fewest
surprises these features should not be combined "magically".
The default changed there and the application at full screen is actually
fully full screen. Meaning we need to make space for the statusbar and
menu.
This code fetches the relevant insets from Android and the GUI honers
them in a couple of choice widgets.
Should we actively be broadcasting a new transaction this now waits for
it to reach the success (or reject) phase before we exit the background
runner.
This fixes a bunch of little issues and possible issues, including the
ability to swipe horizontal the main transaction view before we have a
second tab to scroll to.
This also re-enables the adding of the action that turns a payment into
a repeat payment. Currently our only way to create them.
A bit hidden, but we expect that in future other methods will become
available that make more sense.
The UI can now again click on the repeat payment and show / edit it.
The actual objects are now created elsewhere and the savedPaymentHandler
no longer owns them, vastly simplifying that class.
On Android 'startNet' is called in a more complex way, based on the presence
of network interfaces.
On Android we also don't supply any command line arguments to avoid going
online.
So this is called in the FloweePay_android.cpp file, and it is the same for
foreground and background apps.
For Linux and other platforms the Periodic thus needs to call it manually.
This upgrades to the latest stable Qt (6.8.3) to my surprise the
translator patch still is required and they didn't fix that bug
for 2 bugfix releases now.
To allow a bugfix release to be sent, lets remove the one action
that can open the entire path to repeating payments for now.
Allowing more time to be used for actually making repeat payments
first public release more smooth.
tomFlowee