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.
A payment request, for instance a QR code, which includes an amount to
be paid is expected to not change the to-be-paid amount, uses being
dropped
in the price editing UI is therefore a bit weird. Almost an
anti-pattern.
This honors that concept and when the price is included in the scanned
QR, we change the UI layout to removed the editing widgets and show
static display widgets instead.
This also adds a header menu item to edit the amount to be paid and
get back to the old UI.
Additionally, a new UI is added to show the address we are about to pay
to, likewise reachable from the header menu.
The basic usecases of instapay is that the payment request is filled in
one go (from QR for instance) and thus we try to send.
If that fails (not enough funds or whatever), we disable instapay in
order to avoid 'magic happens' user experiences.
The headers and such items now get localized on the history pages.
We use static strings for the formats to avoid every call converting a c
string to a utf16 qstring, which takes an allocate and a conversion.
A tiny little amount of data kept in global memory to avoid a large
number of mallocs is a net gain, I'm pretty sure.
The design of HD wallets always has a gap, a number of addresses past
the last used one we optimistically also look at.
My code assumed that there would be only one gap, at the end while the
number of skipped addresses were near zero.
Some other wallet, however, had multiple large gaps which messed up the
algorithm.
Now we restart counting gap-addresses every time an address is used in
the sequence.
Fixes#12
This should fix the problem of a certain established wallet not
importing properly.
That wallet has shown to jump 15 or 20 addresses over the gap, which
made me wonder if that actually is a privacy issue and the conclusion is
that, no, if there is no matching transaction on chain, there is no
privacy leakage from just sending the bloom filter and thus the gap has
been increased for main.
Lets face it, listing loads of addresses is not readable. People can't
really get meaning out of that, its just 'data' after one or two.
Showing the hd-path-id (main or change) and an integer is going to be
much more useful for many UX situations, so we provide that information
for the UI to display that instead.
Naturally, the actual address is still available for copy/pasting etc.
This solves the UX issue that the touch-screen keyboard would
overlap on our main content and that we could actally not input
a price properly on mobile at all.
The actual touch area was exactly the checkbox, which is really not that
big an area for a finger to touch.
This assumes that the layout has 10 pixels between components and thus
we eat 5 above and 5 below this component to increase the touch-area to
the max we can.
We ship our own font to not have to depend on the host system's
installed fonts for 'special' characters like arrows and stars.
This is a font forked from the Gnu-free font people, only since that one
is 2MB this is a very much stripped down version with just all the fun
stuff left.
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 now brings the functionality to archive a wallet to the mobile
interface.
Archived wallets don't show up in your main view, do not synchronize
with the network and any balance they may 'contain' is ignored.
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.
On mobile we should not just show a text edit on an otherwise
labels-only screen, because the edit takes focus and opens the
on-screen keyboard. Which makes the amount of usable space
significantly less.
So make the editing user-triggered.
tomFlowee