This redoes the "AccountDetails" page, matching ideas from the mobile
wallet and fixing a lot of bad interactions.
This also looked at the colors in desktop to be consistent and nicer.
Lots of smaller fixes and UI changes.
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.
Now we make sure that setEnabled and loadSettings are always called for
each module info class, even if the save file doesn't have the relevant
properties.
This makes it easier to tie into the setup of the app.
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.
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.
This allows a user to click on a link in a browser with the bch-wif
scheme and we'll handle that with a sweep page on startup.
To avoid this being just-another-special case we introduce a new
module (read: plugin) concept that is a Start-screen type.
The idea is that we can have a generic handling of this type in
various parts of the app without it being specifically about the
wif handling.
Notice that it doesn't matter if the user has the module enabled,
which just operates the display of the menu option to start it manually.
This moves the saving of the enabled-ness of a module to be for the
entire module instead of for each section.
To allow a module to be 'configurable' (for disabling section among
others) we add a virtual method to the ModuleInfo object to allow a
module to save anything it wants.
As we get more modules it turns out that the 'send' tab as originally
envisioned isn't really representative of how we're evolving.
Various items end up being about doing 'stuff' in general. Including
creating a transaction to receive. Only in a very loose way can we
say those are 'send' items.
So, without actually any user-visible changes, this renames the
enum in the module manager and module-section to make it about the
more accurate "action menu".
Plugins can be plugged into the main menu and the send menu already,
this adds the ability for a (section of a) plugin to be loaded as
custom component in the main app, among others.
This upstream refactor stopped passing in the pool by pointer and
now wraps it in a shared_ptr.
A lot less 'address-of' operators and generally cleaner code are
the result.
This sets up a basic system for creating modules on top of the flowee
pay static lib in a way that is ensured to be isolated (modules can't
accidentally use each other's classes)
The setup is made such that the buildsystem does the hard work on
plugging in a new module, making it so that all you need to do is create
a new dir and a "{something}ModuleInfo.h" file and it will get compiled
in.
The point there is to make it not have any merge conflicts and just make
it dead easy to get started.
tomFlowee