To swipe from the left edge now is limited to only 50 'pixels'
instead of half the width.
Additionally, don't allow interaction while the app pin-screen
is showing.
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.
In addition:
- Made it work with latest commit to Flowee/thehub/#5.
- Works better now when decrypting the wallet (accountInfo.isElectrum property
should not be CONSTANT but instead notify on change)
- Made the actual wallet seed phrase type get saved to the wallet rather
than a bool. This type comes from enum HDMasterKey::MnemonicType in
thehub libs.
The CPP now does more of the (heavy) lifting and the UI layer can
ignore
most of the details with regards to there being digits behind the
separator for fiat at all.
The internal change is that the fiat based values are always processed
in cents, even if the cents are not displayed. This solves incorrect
display and generally removes special cases.
One surprise was that the main usecase of pasting is one where the user
activates another app to go and copy data in order to come back to paste
it.
And the Qt clipboard didn't manage to get any notification of clipboard
changes. Even copying data on becoming active had no effect.
So now I just show the paste optimistically when the user comes back
from another screen, assuming the main reason for that was to copy.
This makes available a clipboard helper component in QML.
Based on filters we then can make the 'paste' button visible and
only allow pasting stuff that is remotely useful.
This then also adds a 'paste' button to the transaction-building
module, the 'destination' screen.
We test on desktop, but this component with an actual mouse stops me
from clicking on the "Home" button in the test env. So lets just turn
that off and make the slide-to-open only happen on production devices.
For desktop we now properly support starting a payment when
the user clicks on a bitcoincash link in a browser.
For Android the activation logic _should_ work, except that the
Android specific way has yet to be tied to our app.
Squash of 12 commits, this makes the UX actually useful and
we detect errors and show errors and warnings to the user.
This also adds an 'editable' bool to OutputDetail in order to
disable editing of a payment request address.
Additionally, this introduces the ability for a Payment to carry
a raw script instead of an address. So op-return or more complex
payment requests will be sent just fine.
Fun fact is that our broadcast is INV/SendData, which is two
roundtrips and thus slow, which is needed to be sure we get proper
rejection messages.
The sending of the transaction via BIP70 causes the network to
already know about the tx because the server we send it to has
likely much better Internet than we do.
So confirmation from the payment provider is used to show success
instead of the normal way.
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 QR scan page now also allows showing the destination address
while the number keypad is up, being smarter with the layout of
the various lines in order to fit the important info on screen.
Additionally we require the user to first enable the 'edit amount'
option before we make available the option to 'send all'.
People that only use one hand will no longer need to use the other to
reach the button at the top for the menu.
Instead we now allow a swipe in the bottom left corner, swiping to the
right will make the menu open.
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.
this also changes the API propertes that handle encryption details a
little. Making them faster and the meaning follows the logical
conclusion of the naming better.
Specifically:
when needsPinToOpen would return true, now needsPinToPay will also
always return true.
When the user is trying to create a transaction we start with the
currently selected wallet. The user is able to change to another wallet
in such flows, but we stop them from seeing
the fully encrypted wallet as the workflow would just become too tedius
and confusing.
Now the mobile skin can also enable the per-wallet 'count-balance' bool.
If set to false it makes the balances of the wallet no longer be visible
or indeed counted in the overview. Specifically the AccountSelectorPopup
* Add a total balance label at the bottom if we have more than one
wallet.
* Add lock icons for encrypted or even partially encrypted wallets
* Add label to indicate an encrypted wallet needs opening before it can
be used.
* Fix spacing in case of larger fonts.
This detects that the currently selected wallet is fully encryted and if
it is, it shows a password request page on top of the current screen.
The default setup aims to have people type a PIN in numbers to unlock
the wallet, but we also provide a way to make it use a textual password
instead.
When the user starts editing the text label, the way out is to use the
(virtual) keyboards 'enter' or 'done' button.
We mark this button as disabled while editing to avoid weird situation.
This also works around the application completely hanging in Qt651 on
the phone. Hanging as in: Android suggests it to be killed.
This is a long overdue cleanup around the ideas of entering
numbers in Flowee Pay.
The core dataclass BitcoinValue now keeps track where the number
came from, either user input or some calculation. This allows
us to have the Fiat and the Coin price stay in sync without weird
problems.
The one we type uses a string, the price field that we are not typing in
is then a slave and we follow the auto-generated number as the
source.
This solves a host of known issues:
* Editing of value objects is much more consistnnt and predictable now.
* Switching to a different fiat type now properly re-calculates the
values that are slaved. So if the primary is a BCH value then the fiat
value gets the new exhange rate instantly applied.
* Switching to a different fiat type properly applies having a separator
So if you go from euro to Japanese yen, we now remove the separator
and the numbers behind it.
* Changing the app setting from BCH to mBCH now properly updates all
amounts. Notice that the user-typed string wins, if you typed 2 and
then change to mBCH we assume you wanted 2, not 2000.
* Paste now works more logcally.
* Cursor is no longer sometimes invisible, requiring backspace to make
it show up.
And last we now protect against too large numbers. It is seen as an
error to type a number above 21 million BCH.
Fixes#19
As the name is so much wider the widget didn't work well, this
makes the name not overlap.
Additionally, added a space beteween the currency name and
the numbers.
tomFlowee
Calin Culianu