This avoids problems with needing to tap it twice to show and allows for
better reuse of our own components and makes sizing and positioning not
black magic.
When a repeat payment is detected to soon be eligable for sending, but
the user has not approve it yet, we show a notification from the
background process to entice the users to go and approve it.
This popup now also carries a 'disable' text which disables the repeat
payment, effectively shutting up this and further notifications.
The tricky part to make this work is that the notification is showing
while the application is (likely) not actually active.
This takes the strategy that the notification carries some extra
details. Among others a newly introduced unique id for a notification
itself, and also some text to show on actually processing the disable
action.
The processing just writes a file, to avoid complexity and side-effects.
The file will then be read on start up (either foreground of background)
to action on the lines in there. So the item will be disabled on first
load.
When the title and the 'current value' text are both long, typically
with a huge font selected, they now avoid overlapping by moving the
value label down.
This makes the "new transactions above this line" concept more coherent.
We now save the last known transaction in the model, which is only
loaded in the GUI version of Pay.
Then if new transactions are found (or created) in the background runner
then the next time we start Pay, they will be marked as such.
This also adds some logic to the UI to detect that the history is
actually the visible component right now, and if it is then we start
an 80 second timer that, after expiring, will reset the last seen to
the most recent transaction.
We already check for duplicate running, instead of showing the non
functional UI, this changes to instead wait for the lock to become free
after which we run the 'init' and load all the data.
This avoids people approving when they intent do just open the details
screen. User tests showed that the confusion of hitting the checkbox
when the details screen was aimed for was masking the actual action
taken, making it dangerous to leave it larger.
This shows more details, like the target address.
This also made the screen able to handle multiple outputs in a payment,
though that is a bit tricky with regards to which values we allow
editing.
The crazy animation caused it to show a little at the top on hide, so
now we move it further off screen to avoid that.
Additionally this removes the semicolons from these pages where
applicable. It's cleaner without them then sometimes there sometimes not
there.
As noticed by John, the import wallet requires a date and so the parallel
should be sought in the display of backup data to also show a date and not
a height.
We show the date of the first transaction here, which is more sane than the
initial creation date of the wallet.
If there is no transaction we show the date based on the registered wallet
start height.
Since the whole thing with Android going full screen with margins, the
combobox popup idea started showing a big flaw; Qt no longer clips the
window on top to the content area and thus your top and bottom item may
become impossible to select.
This replaces the combobox with a new component; a thumbler. Based on
the extremely basic one from QQComponents we introduce our own and use
that to select the year and month in the import screen.
This takes user feedback on the spacing and adjusts it
further.
The intention is to avoid a jump when the text line of the
sync status goes away, while not taking space for it always.
With the sync-state label being removed the whole UI used to jump, we
solved that by pushing in the labels a little based on the assumption
that they won't be there very long.
This cleans up and re-does the 'wallets' page, as it is named in the
menu.
This adds some features and inlines some not reused content but mostlie
redoes the UX to something more satisfying.
tomFlowee