I mean, yes, the fancy enums help readability, but the fancy enums
actually pull in a rather large dependency that adds hundreds of
kilobytes to the deployment. Then just ints don't look so bad
anymore, do they?
This section type means that the module will have it's icon shown in
the 'Explore' tab always, it can not be disabled by users and as such
it just becomes an overflow of the main app avoiding worry about a
module not being found.
This moves the decision if it is importing out of the wallet and we stop
using a broken heuristic.
Also cleanup the API usage of the hd masterkey format in the wallet
header.
This is probably a good first milestone, the UX is pretty decent
and the wanted functionality is there.
Various todo's are still there which mostly of the cleanup type.
The toggle on some devices takes a second or 2, as such it may be
tempting to press multiple times waiting for the change.
This hardcodes a 3 second wait to increase the UX a little.
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.
In the send-sweep module as well as in the PayWithQR this removes
the UserIntent handling and instead moves that to the main.qml
exclusively.
Additionally in the send-sweep module the camera work is split
into its own page, like in the other parts of the app. This helps
us avoiding hacks when we want the main functionality without the
camera.
This is the last of the series of reworks, we should have all
former functionality working again.
Continuing the 'rework send page' series.
This moves stuff that had no business being on the "Send" page to
live on a new tab instead. Prime example was the 'sweep' module
that creates a transaction we send, but to ourselves. So it's far
fetched that it fits in 'send'.
This reverts commit 9f69241bbb.
Reason for revert is that instead of renaming the send, we're now
creating a new tab instead. So we'll keep "Send" and add a new one
as well.
The initial design has done well for over 2 years, but problems
are starting to show.
This does a bit of cleanup in the UX and many cleanups in the
underlying architecture that were the result of those UX choices.
We remove the clipboard (paste) concept from the camera pipeline
completely and simply make it a new top-level button "paste" on the
send page. This helps discovery AND helps architecture!
The both workflows now also become 2 stage affairs, when the button
is pressed we open a page that does the scanning or pasting and then
introspects the actual data in order to redirect to the right page.
This means that we auto-detect if the scanned item is an address or
a private key or whatever, and handle it appropriately without needing
any user interaction.
This removes the support for older than qt65 for mobile.
Qt65 was released April 2023, making the code we now release not
needed anymore. End of 2024, and us moving to 6.8 feels like we're
safe in removing it.
This takes the NotificationManager and splits it into multiple
compile units based on the backend that is available.
The 'dbus' was the only one available so far (which serves
kde/gnome desktops) and this is moved to its own file.
This adds android support as well, but so far only for block
notifications (when a new block is mined).
This reverts a broken Qt patch wrt translation selection. See QTBUG-131894
This removes various Qt features from the build that we don't need
in order to keep the library size down.
The qtdeclarative module went from 4285 ninja tasks to 2387, or for the
android buld from 4117 to 2251.
tomFlowee