Changes in contact data caused via calls to any contact related APIs wouldn't be
reflected in the UI because it doesn't re-fetch the updated state from status-go.
This commit makes the contactsService `fetchContacts` API public so it can be
used on the profile section control to re-fetch contact data when changes to
contacts have been emitted.
refactor: wallet: connect current account
refactor(@wallet): load collection and connect to store
refactor(@wallet): add boilerplate for accounts creation/generation
refactor(@wallet): watch account
refactor(@wallet): Add account generation
refactor(@wallet): display all accounts
refactor(@wallet): switch account
refactor(@desktop): update current currency
refactor(@desktop/wallet): token action
refactor(@desktop/wallet): Add update account
refactor(@desktop/wallet): filter chat account from wallet
refactor(@desktop/wallet): Update currency attribute
refactor(@desktop/wallet): Fix display of various balances
refactor(@dekstop/wallet): handle current account changed
refactor(@wallet/desktop): add notify event on main section
refactor(@desktop/wallet): Push events from service
refactor(@desktop/wallet): handle all tokens event
refactor(@desktop/wallet): refresh accounts on event
refactor(@wallet/desktop): formatting of currency balances
refactor(@desktop/wallet): load collectible
refactor: refactor wallet transaction history to the new architecture
update status-lib
refactor: add back events for the transaction history
refactor: support multiple accounts in the transaction history
add profile module
add boilerplate for profile section
add profile module
add profile module
fix variant
use accounts service
get identityimage to work
cleanup
add other contacts services
add contacts service
make contact section compile with refactor
fix controller and service interfaces
add about section
cause it logically doesn't belong there as it is not a service. It is a global
instance, exposed to the UI (qml) part. Since it represents QSettings it should
be maintained from the single point.
Parent modules are exposed to submodules using their base class instead of
concepts, since using concepts is not possible to create a second level nested
modules.
Initial structure for MainModule containing ChatSectionModule and
CommunitySectionModule is added, as well as initial structure for
StartupModule containing OnboardingModule and LoginModule.
Order of execution is updated and adapted to the current app state.
Main module gets loaded once a user is successfully logged in.