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 QML design of styling is that one extends the "Template" version
of a component. With the Basic, the Fusion etc already provided.
But after upgrading to Qt6.9 that styling for Popup changed and broke
the look of Flowee Pay.
So, we no longer use the Basic styled class, but the bare one which
should never change.
This additionally simplifies a lot of the workarounds surrounding insets
and other stuff that existed in the Basic.Popup, and we just don't set
in our own "style" of Popup.
Beautiful result, lots of complexity removed from AccountDetails,
TransactionListItem and very much from PopupOverlay
The non-themed import basically is just a proxy using some
auto-detection to find out which theme to use.
As the app only uses the basic theme, this is what we'll import.
We remove the block notification feature, as that was nice but useless.
This instead introduces a way for a transaction we created to be marked
as needing monitoring and when a block comes in we create a notification
explaining it has been mined.
This adds the ability to paste an almost correct seed phrase, for
instance when the last word is cut off.
We also provide a new UI to propose words while typing the seed,
allowing the user to tap on the words instead of having to finish typing
them.
This changes the notes property to be only set by the user of the
BroadcastFeedback.qml, and not from inside anymore which could break the
property binding causing strange things to happen.
This adds a lock to ensure that the app is not started twice, which
would be bad for data consistency.
The second version will just show a simple window stating it is already
running. While it would be nice to make it more advanced, I don't think
that is useful to spent time and code on.
This moves the creation of the portfolio to happen the moment we
finished loading. (wallets were loaded either way)
The networking is the part that now waits for the user to unlock before
it does anything.
On the desktop activity view the prices are right aligned but due to
adding fiat prices this means that the bch amounts are not lining up.
This adds a little space between the two in order to make them much more
readable.
This widget is only used by the desktop, so no point in storing it in
the Flowee Subdir.
It basically turned out that it is so simple to do this that mobile got
its own more specilistic version.
This now has a bit of a jittery bahavior when we're waiting on the
network and maybe to find some peers.
Going back to normal smooth progressbar behavior as soon as one block
has been downloaded.
The idea is that if you send a transaction you may want to see it
getting confirmed.
This now shows directly in the main UI in an unobtrusive manner with
checks.
This moves the heuristic to exist only once and avoids duplicating it.
Additionally this increases the checks accuracy.
Last, the 'moved' price in desktop now is white to indicate it is
not a balance change.
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.
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.
tomFlowee