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.
We now fix archive being there when it makes sense, and
also fix the focus being lost after toggling the archivi-ness of a
wallet. Which means that hitting 'Ctrl-Q' will correctly close the app
after.
As we still support older versions of Qt, this moves to load
the MultiEffect (blurring specifically) dynamically and avoids
the entire project failing if the effects module is not found.
The effects module was introduced in Qt6.5
A peer that has not yet handshaked is now show in this view, giving a
better indication of what is going on on platforms that do not have easy
access to a log file.
After we changed the TX to always have a date at creation, the desktop
GUI code's assumptions were undermined and it would be able to show
weird stuff.
This fixes it properly and shows the right data.
This is likely the oldest component in the app and it was
really in need of a rewrite.
The state of peers is shown much clearer now, we use a proper
model in order to avoid the jumping and we use a more safe
way of getting at the data.
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.
This is the format used by (older) Electron Cash wallets. It may be
useful to users wishing to use their older EC wallets with Flowee Pay.
Highlight of changes:
- Import wallet UI now auto-detects whether it's Electrum or BIP39. Note
that in some cases a valid BIP39 seed is also a valid Electrum seed.
The user has a UI element checkbox for "forcing" Electrum
interpretation in such cases.
- Electrum seed phrases always use derivation path "m/" so this is
forced on the user as the only path available in the Electrum case.
- Wallet file format has a new tag to indicate whether the seed phrase
is electrum or not. Only present in the electrum case, otherwise it's
omitted from the serialized data.
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.
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.
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.
A Payment object now has a user-typed address,
a formattedAddress which is a properly formatted cash-address
and last a 'niceAddress' which is the same cash-address but without the
chain prefix.
This cleans up the usage and removes some code from the GUI that did the
string manipulation there.
This redoes most of those pages to look much nicer and in-place.
This also disables the 'create' button when the derivation path is not
correctly entered.
This brings the new 'privacy mode' to use the standard widgets
and make the UX more smooth.
The swiping between pages / wallets is more visually satisfying.
We update the sync label to have a live counter of how long ago
the last block came in. (both front-ends)
A wallet can permanently be labeled a 'private wallet' which is a simple
boolean.
Then when you may need to hand over your phone to a clerk, all you do is
quickly enable the 'private mode' which is sufficiently deep in the menu
to make it hidden.
The effect is that all wallets marked private will be hidden for the
duration of that feature being on.
The feature to show only the exchange-rate based value on the
main screen doesn't make sense on anything but mainnet due to
the simple fact that thats the only one that has an exchange rate.
We hide the feature on testnet and make it always show the BCH
value on the overview screens.
Notice that the actuall setting, as written in the config file,
is shared between chains. We only have one confg file. So any
solution with default values would not work.
tomFlowee
Calin Culianu