- Remove unneded mailserver request when joining a channel
- Add extra details to mailserver logs (request id, and num batches)
- Add signal emitted each time a batch is processed
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
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.
Turns out we've been accidentally resetting the channel's `position`
property to `0` by not sending it over to status-lib's underlying
`editCommunityChat` API.
This fixes it by using a newer version of status-lib which supports
the `position` paramter in `editCommunityChat` and then sending that
value along from the edit channel popup.
Fixes#3672
- Display loading indicator on login when mailserver messages are requested
- Fix bug where the mailserver that's selected as soon as you login is disconnected while being still in the process of connecting instead of waiting until 10s have passed to try connecting to a different mailserver
- Use status-go version that fixes an issue fetching mailserver messages when more than 999 messages are being verified if they're in the cache
- Display loading indicator on login when mailserver messages are requested
- Fix bug where the mailserver that's selected as soon as you login is disconnected while being still in the process of connecting instead of waiting until 10s have passed to try connecting to a different mailserver
- Use status-go version that fixes an issue fetching mailserver messages when more than 999 messages are being verified if they're in the cache
fixes#3659
Wallet2 needs its own event otherwise they wallet1/2 mixes
and as not everything is implemented in wallet2, it crashes
In this particular case, the account is added into wallet1 but trigger
an event intercepted by wallet2, wallet2 doesn't have the new account
and crash
Fixes: #3473.
Sometimes when blocking users and changes channels, blocked user messages would still appear.
This PR fixes the issue by toggling a `hide` property on messages from a contact when that contact is blocked or unblocked. Previously, the messages were only removed from the view when the contact was blocked, but when the view was reloaded, that state was not tracked correctly.
In case clicked channel:
- exists in a community -> the app will switch you to it
- doesn't exist in a community, but exists in the public chat list -> the app
will switch to `Chat` section and also to the appropriate channel there
- doesn't exist in a community and doesn't exist in the public chat list -> the app
will switch to `Chat` section and join new channel
Fixes: #3489
This feature works for MacOs only, for now.
On login, whether new or already created user may select between options:
"Store" - store password to the Keychain
"Not now" - don't store it now, but ask next time again
"Never" - don't store them ever and don't ask again
Selected preference may be changed later in:
`ProfileSettings > Privacy and security > Store pass to Keychain`
On the next app run, if `Store` was selected, a user will be asked to confirm
his identity using Touch Id in order to log in the app. If any error happens
he will be able to login using password.
Fixes: #2675
From now on we are able to access local settings (settings and global settings)
on the nim side, not only through the qml.
This change is required as part of the feature issue-2675.
App is responsive to the OS theme change event.
Now we're following system set theme when the app is started.
Corresponding part on the side on nimqml is added.
Corresponding part on the side on dotherside is added.
On the side of dother side we had kind of a memory leak, cause objects added to
the filter were not deleted ever. When the app is closing, it just removes
filters, but doesn't delete them.
I faced a logical issue, that we were sending qmlengine pointer to the
installEventFilter method, instead object which may or may not rely on the
qqmlengine instance, that is fixed also.
Fixes: #1725
Searching messages by some term for a specific channel is added on the side of status-go and an
appropriate part on the side of nim is developed accordingly.
Fixes: #2912
Searching messages by some term for a specific channel is added on the side of status-go and an
appropriate part on the side of nim is developed accordingly.
Fixes: #2912
There was a change in StatusQ that introduced dividers for modal footers
and headers, so we don't need to put them in the content manually anymore.
This commit removes the no longer needed ones.
Changes the community invitation text notifications from
“Upgrade to see a community invitation”
to
**InviteUsersToCommunity**
```golang
fmt.Sprintf("You have been invited to the community %s", community.Name())
```
**ShareCommunity**
```golang
fmt.Sprintf("Community %s has been shared with you", community.Name())
```
Closes#2344.
Add ability to edit name, description, and private fields of a community channel.
feat: Display community channel description
Ensure the width of the description does not surpass the context menu and instead wraps to the next line.
feat: After channel is created, set it as the active channel
Closes#2344.
Add ability to edit name, description, and private fields of a community channel.
feat: Display community channel description
Ensure the width of the description does not surpass the context menu and instead wraps to the next line.
feat: After channel is created, set it as the active channel
Fix a typo in a recently added header file in DOtherSide that causes problems
on case-sensitive filesystems, e.g. on Linux.
Also unify the build command for DOtherSide across platforms.
Prior to this commit, loaded channels and chats would always be
sorted by date of last message received, with the latest one being
moved to the top of the list.
When new channels or chats are joined, they are added on top of the
list as well, however, when the application is restarted,
those new joined chats would not necessarily show up at the top anymore
becaue nothing keeps track of when a channel was joined, which should
be taken into account when preserving the order.
The changes introduced in this commit solve this by introducing a
new `joined` property on the `Chat` type which gets updated with
the current timestamp whenever a channel is joined.
It also depends on the changes made to the `status-go` client, which
have to land first: https://github.com/status-im/status-go/pull/2158Closes: #1832
Add an event filter to `qApp` that can detect a dock icon click (in macos) when the main window is hidden or closed.
When the event has been triggered, the main window will be shown again.
Co-authored-by: Boris Melnik <82511785+borismelnik@users.noreply.github.com>
In the repo:
```
$ bin/nim_status_client --help
```
In the packaged app (macOS example):
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --help
```
Output:
```
Usage:
nim_status_client [OPTIONS]...
The following options are available:
-d, --dataDir Status Desktop data directory.
```
**Using the option**
```
$ cd ~/status-ci-builds/master/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/master"
```
In another terminal:
```
$ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242"
```
The path supplied can be relative or absolute, and can be specified with
`--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`.
Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]`
or `-d [path]`.
The name of the option follows Nim's partial case-insensitivity rules, so
`--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See
[Identifier equality][ieq] in the Nim Manual.
It is possible to run the same build in multiple terminals by supplying
different `--dataDir`, i.e. this works:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some1"
```
In another terminal:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some2"
```
**Windows**
It is recommended to use a Git Bash or MSYS2 terminal when invoking
`bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production
build) on the command-line. The reason is that if the exe is invoked in a
session of `cmd.exe` it will return to the prompt immediately; the app will run
but there will be no output in the terminal. In any case, the `--dataDir`
option will take effect whether the exe is invoked in `cmd.exe` or a
recommended terminal.
For development builds, when invoking `bin/nim_status_client.exe` directly
instead of via `make run`, because e.g. you wish to use the `--dataDir` option,
it is required to first setup the `PATH` environment variable correctly. See
the `run-windows` target in this repo's Makefile for more information.
**Linux**
The `--dataDir` option may be passed to command-line invocation of a
production (AppImage) build in the same way as passing it to a development
build:
```
$ Status.AppImage --dataDir:/path/to/wherever
```
For development builds, when invoking `bin/nim_status_client` directly instead
of via `make run`, because e.g. you wish to use the `--dataDir` option, it is
required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the
`run-linux` target in this repo's Makefile for more information.
---
BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling
of the status-go directory rather than a subdir of the status-go directory:
```
Status (app data directory)
├── data (status-go directory)
├── qt
└── tmp
```
Because app settings are stored in the `qt` directory that means that existing
installations will lose their customized settings.
At app startup, it would be possible to detect `Status/data/qt` and if
`Status/qt` doesn't exist yet then copy `Status/data/qt` to
`Status/qt`. However, there was some concern that behavior could lead to
problems later on if we forget the workaround is in place. So for now that
settings preservation strategy has not been implemented, but it might be before
this commit is merged pending full team awareness/consensus.
---
Command-line option support is provided by
[nim-confutils](https://github.com/status-im/nim-confutils).
The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of
passing a "define" option to the Nim compiler: `-d:development` for development
builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make
V=1 pkg`). Passing the correct option is handled automatically by the Makefile.
A make variable named `RELEASE` has been introduced, which defaults to
`false`. Presently the `RELEASE` variable should not be set on the command-line
nor in CI as more work needs to be done to toggle the proper compiler flags. In
the case of Status Desktop, "release vs. debug" is a concern orthogonal to
"production vs. development". At present, production builds and development
builds are all debug builds, but that will likely change in the future: we can
have non-release CI production builds and local development builds be debug
builds, while release builds in CI would be production builds with
`RELEASE=true` (the compiled executable will be fully optimized).
Prior to the changes in this PR, symmetry is somewhat lacking between
development and production (packaged) builds with respect to the concept of the
"data directory". In development builds the root of the repo effectively serves
as the `Status` directory used by production builds, e.g. on macOS
`~/Library/Application Support/Status`. Also, there's a bit of confusion as to
whether "data directory" refers to a directory for the desktop app's overall
data (including status-go data) or to the specific directory used by status-go.
This PR attempts to provide symmetry and reduce confusion:
* The term "data directory" means the directory used by the desktop app to
store multiple kinds of data and is not a reference to the subdirectory used by
status-go.
* For development builds the "data directory" defaults to `./Status/` relative
to the root of the repo.
* For production builds the "data directory" default is the same as before,
e.g. on macOS it's ` ~/Library/Application Support/Status/`.
The directory used by status-go is `Status/data/`. To be clear, that should be
referred to as the "status-go directory" and not the app's "data directory". It
would nice if we could rename it from `Status/data/` to `Status/status-go/`. We
can do that, I already checked that it works correctly; however, for existing
installations it would require that at app launch we check for the presence of
`Status/data/` and rename it to `Status/status-go`. While simple enough to do,
I was concerned that there might be edge cases where the directory rename could
cause a problem (e.g. if another copy of the app is running) so chose for now
to stick with the status-go directory being `Status/data/`.
---
**NOTES**
More work needs to be done to ensure that all data written by the app is
contained in the default or cli-specified data directory. Currently, both
development and production (packaged) builds are writing to common directories
outside of the data directory, e.g. located within `~/Library/` on
macOS. Changing that behavior seems like it will mainly involve changing
defaults related to Qt components such as the web engine. See:
https://github.com/status-im/status-desktop/issues/1141.
In general, additional refactoring could be done in the future. For
example, implementing `StatusDesktopConfig` in
`src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine
for now, but better code organization is desirable.
---
Closes#2268
[ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
Bump dotherside to a commit that is on its current master branch. The previous commit and the current commit have the same contents, however the previous commit lived on a branch, and not on the master branch of dotherside.
An attempt to bump nimqml to its master branch commit resulted in an error, which has been logged https://github.com/status-im/status-desktop/issues/2275. Instead, the commit change here is the same as dotherside — moving the commit hash from its branched version to the commit that lives on the master branch line. However, as mentioned already, it is not at master HEAD due to the error.
Richard Ramos
Anthony Laibe
Alexandra Betouni
Alexandra Betouni
Jonathan Rainville
Pascal Precht
B.Melnik
Iuri Matias
Sale Djenic
Eric Mastro
Khushboo Mehta
Andrei Smirnov
Michael Bradley, Jr
B.Melnik