Fixes: #2725.
When clicking on the History tab for a wallet account, there was a QML error for `qrc:/app/AppLayouts/Wallet/WalletLayout.qml:113: TypeError: Property 'checkIfHistoryIsBeingFetched' of object HistoryTab_QMLTYPE_503(0x7fed35da2710) is not a function`. This must have been reintroduced when StatusQ objects were introduced. It has now been removed.
chore: change log level to warn for non-archival node
Previously, there was an error being logged for non-archival infura nodes being used (typically in dev). This log level has been reduced to a warning as the application still functions with non-archival nodes.
Validation check is updated, so user cannot enter zero or less than zero value for "gas amount limit" or "per-gas overall limit".
In gas.nim a crash prevention check is added.
Fixes: #2753
Validation check is updated, so user cannot enter zero or less than zero value in amount input field.
Also in utils.nim a crash prevention check is added so if we try to convert a less than zero float number to an unsigned number, app won't crash any more, but that casting will return a zero as unsigned int number.
Fixes: #2755
Fixes: #2686.
Previously, when using a new account, joining a chat then creating a community and then returning back to the chat would not show a chat at all and instead show the default chat view. This was due to the previous index not being set when there were no other channels in the chat.
This has been updated such that the previous channel index is set when switching from chat to community and no previous channel index has been set.
# Conflicts:
# src/app/chat/view.nim
Fixes: #2649.
Upon receipt of status-go signals which included communities that have been left (`joined: false`), those communities were being rejoined automatically when they should not have been.
fix(communities): Invitation bubble button state updates
The community state inside of the invitation bubble was not reactive to any community actions (such as joining, leaving, updating). In addition, requesting to join a community changed the button’s text to “Pending”, but upon approval, the button’s state was not updating.
The component was setting an observed community in the Component.onCompleted event, which was occurring for all invitation bubbles, but because the community wasn’t bound correctly to the bubble, once a bubble with a different community was encountered, the community in context of the bubble wasn’t updated and instead used a local copy. Once the community was bound correctly (to be reactive), the states started working correctly.
The invitation bubble has been simplied so that it has states instead of using lots of if/else statements inside of the property bindings. This simplified the component’s logic for things like onClick action and made it a lot easier to read and modify.
add getSettings methods to src/status
fix issue with calling getSettings; document issue
remove most direct references to libstatus; document some common issues
remove most references to libstatus wallet
add mailserver layer to status lib; remove references to libstatus mailservers
remove libstatus accounts references
move types out of libstatus; remove libstatus types references
remove libstatus browser references
refactor libstatus utils references
remove more references to libstatus stickers
remove references to libstatus constants from src/app
remove more libstatus references from src/app
refactor token_list usage of libstatus
refactor stickers usage of libstatus
refactor chat usage of libstatus
remove libstatus references from the wallet view
remove logic from ens manager view
fix issue with import & namespace conflict
remove unnecessary imports
refactor provider view to not depend on libstatus
refactor provider view
refactor: move accounts specific code to its own section
fix account selection
move collectibles to their own module
update references to wallet transactions
refactor: move gas methods to their own file
refactor: extract tokens into their own file
refactor: extract ens to its own file
refactor: extract dappbrowser code to its own file
refactor: extract history related code to its own file
refactor: extract balance to its own file
refactor: extract utils to its own file
clean up wallet imports
fix: identicon for transaction commands
Fixes#2533
Fixes: #2601.
Kicking a user and re-inviting them now correctly redisplays the join/decline options. Other combinations of User B leaving or declining an invitation are not handled. Please see the notes below for clarification.
Additionally, the group invite popup (that shows the list of members belonging to the group) correctly shows when a user is kicked or when a user leaves the group in real time. Previously, the popup needed to be reopened to display this.
fix: decline invitation crash
Declining a group invitation was crashing the app. This has been fixed.
### NOTES
1. In the case where User A invites User B to a group, but User B declines (or User B joins, then leaves), then from a status-go standpoint, User B is still part of the group, but the chat is marked as `active: false` for User B. This creates a situation where User B cannot re-join the group once s/he has declined the invitation. @cammellos mentioned there possibly will need to be a refactor of cab6281dc5/protocol/messenger.go (L1710) (which, by retaining User B as a member, effectively prevents the re-invitation) once “swipe to delete” is implemented on mobile. There is an activity center notification received for User B that is meant to allow re-joining of the group when the notification is accepted. The activity center notification received from status-go looks like the following:
```json
"activityCenterNotifications": [
{
"id": "0x0e342d33",
"chatId": "e342d33f-dd05-4d7b-b14e-b5335e1a3ee9-0x043bf46aa874c377a34946eab67a32cf36c15907b328216dfce375d169fed7d81c21cada3229db1fd37c762d2c02702111a646657feca6621e2e948febcf378fb4",
"name": "test-22",
"type": 2,
"lastMessage": null,
"message": null,
"timestamp": 1623305612000,
"read": false,
"dismissed": false,
"accepted": false
}
]
```
Fixes: #2539.
Transaction history is now correctly being fetched from status-go as per mobile. Firstly, when accounts are added (ie as watch accounts), `wallet_checkRecentHistory` must be called first so that the status-go db is populated. After that, `wallet_getTransfersByAddress` can be called. On app load, when we run the `initBalance` logic, we are calling `wallet_getTransfersByAddress`, asking for the last 20 transactions with the `loadMore` parameter set to false. When the user navigates to the Wallet > History tab, they can then click “Load More” to fetch more transactions from status-go. Once the number of transactions returns false below the expected amount, the remaining transactions to fetch have been exhausted and the “Load More” button is disabled.
feat: add non-archival node warning to the UI to indicate to the user that they may not have complete results
feat: set active account to the added account
Once an account is added to the wallet, that newly added account is selected as the active account.
1. The “load more” button is active when new transactions that aren’t already displayed are returned from `wallet_getTransfersByAddress`. This is the only way to enable or disable the “Load more” button as status-go is not able to return information regarding whether or not there are more transactions to be fetched. The downside to this is that lets say the last page of transactions is returned, but there are no more pages left. These returned txs are not currently displayed, so the “load more” button will still be enabled. However, the next click of the button will return 0 results, thus disabling it. It’s effectively an extra click to get to the disabled state.
2. For more information on how the `toBlock` parameter operates for the `wallet_getTransfersForAddress` RPC call, see https://notes.status.im/XmENTrVRRaqhwE4gK0m8Mg?view.
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
Fixes: #2618.
The main culprit was that `self.pinnedMessagesList` did not contain the `self.activeChannel.id` because it was correctly upserted in `upsertChannel`.
To fix this, when calling `upsertChannel`, `self.pinnedMessagesList` was checked if it contained an entry for the upserted channel first before adding it to the list.
Nil checks were added to parsing the messages RPC response in case specific fields were not returned in the response.
In addition, a copy/paste error was fixed in `asyncMessageLoadTask`.
Fixes: #2318.
Currently, when exiting the app and the sticker packs task is being run, the app will wait for the sticker packs task to completely finish before exiting the app. This causes a beachball to be displayed and can cause a long delay while waiting for the task to finish.
This PR passes an interrupt signal to the sticker pack loading task in the threadpool thread. The task loads the interrupt on each iteration of its loop (each sticker pack to load) and also during the processing of each sticker pack (getting of sticker pack data). This allows the application to exit neatly.
fix: Handle shutdown of long-running (marathon) task before login
Currently, we wait for the “loggedIn” message to be passed to the marathon task runner before initialising the mailserver model. We were, however, blocking the thread until “loggedIn” was received, meaning that if “shutdown” was received (as it is when cmd+q is pressed), this message would be ignored and the application would have to be forced to quit.
This PR adds logic that not only listens for the “loggedIn” message, but also for the “shudown” message. Once the “shutdown” message is received, the marathon worker thread exits.
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
There is an unknown state that the data dir seems to get in that causes the application to crash when checking pending transactions. This is fixed by checking if the pending transactions RPC result has a `”result”` field first before attempting to read it.
### NOTE:
Clearing the data directory fixed the issue for me, however I do not know what caused it in the first place. While the crash was happening, there was also an error appearing in the logs:
```
ERR 2021-05-18 15:40:47+10:00 rpc response error topics="rpc" tid=3893906 file=core.nim:24 methodName=wallet_getPendingTransactions payload=[] result="{\"jsonrpc\":\"2.0\",\"id\":0,\"error\":{\"code\":-32000,\"message\":\"no such column: transaction_hash\"}}"
```
After clearing the data dir, this error also went away.
When inviting contacts to a community, Status Desktop suggests a list of
all contacts, even if contacts of that list are already members of the community.
This commit introduces a new flag to `ExistingContacts` component that
allows for configuring whether community members should be hidden or not
Fixes#2502
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>
Fixes: #2365.
Previously, suggestions for mentions were showing profile pics even for users who were not contacts. Now, profile pics are only shown for those users who are contacts. The user’s identicon is shown otherwise.
fix: user thumbnail not shown when no profile pic
When a user was a contact, but didn’t have a profile pic, an image would not be loaded and a ‘reload’ image would be shown instead. With this PR, if the user is a contact and they do not have a profile pic, their identicon will be shown instead.
Fixes#2448.
Currently, if a wrong password is entered when generating a wallet account, the app will crash due to attempting to decode a `GeneratedAccount ` from an rpc response containing only an error.
With this PR, we are detecting if an error is returned in the response, and if so, raising a StatusGoException. This exception is caught in the call chain, and translated in to a `StatusGoError` which is serialised and sent to the QML view, where it is parsed and displayed as an invalid password error in the input box.
refactor: remove string return values as error messages in wallet model
In the wallet model, we were passing back empty strings for no error, or an error as a string. This is not only confusing, but does not benefit from leaning on the compiler and strong types. One has to read the entire code to understand if a string result is returned when there is no error instead of implicitly being able to understand there is no return type.
To alleviate this, account creation fundtions that do not need to return a value have been changed to a void return type, and raise `StatusGoException` if there is an error encountered. This can be caught in the call chain and used as necessary (ie to pass to QML).
refactor: move invalid password string detection to Utils
Currently, we are reading returned view model values and checking to see if they include a known string from Status Go that means there was an invalid password used. This string was placed in the codebased in mulitple locations.
This PR moves the string check to a Utils function and updates all the references to use the function in Utils.
This commit does a couple of things:
- add StatusQ as a dependency (https://github.com/status-im/StatusQ)
our emerging component library
- updates the rcc generation script to follow symlinks as well
- add qrc:/./StatusQ/src as import path
At the time of creating this commit `StatusQ` provides only the StatusIcon
component, but more will be added in the future.
Fixes: #2364
The Send Message button click event was erroring due to a refactor that had been done to allow for changing app sections.
This has been updated to follow the current way to change app sections.
fix: “Send Message” button crash in communities
This required switching from communities to normal view.
fix: crash when clicking channel link in community message
When a message in communities contains a link to another channel (ie #otherchannel), the search for this channel needed to be updated to also search for the channel by name, allowing for switching between channels within a community by message link. Additionally, when in a community, if the channel was located in a normal chat, it will switch the view to the normal chat after being found.
This commit ensures that, once a community was imported, the application
will listen to the newly introduced `community.found` signal, which will be
emitted by status-go.
The signal exposes a `Community` object that is then used to add a
community item to the community list in the UI.
**This can only land after https://github.com/status-im/status-go/pull/2177 has landed first!**
Fixes#2024
Fixes#2312
This will reset the QT settings of all users, since we change from using the address to using the pubkey.
The reason for that is that the account address also called keyId is somehow not set correctly on first login. The pubkey stays constant on the other hand. So using the pubkey is better.
Fixes: #2418.
Chat notifications for one-on-one chats were showing only a user’s alias and not their ENS name if they have one.
This PR now shows a user’s ENS name if they have one, or their alias if they don’t in one-on-one chat notifications.
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
This commit introces global settings that apply across accounts used
inside the application. This is useful when settings like the selected
locale should b the same across all accounts.
Closes#2144
Current settings caching logic was inefficient when attempting to retrieve settings that contain the sensitive mnemonic. While those calls were limited to the login logic, each call would need to round trip to status-go to get all settings when they wanted to include sensitive data, as the cache was not being updated for these calls.
This PR updates the cache regardless if sensitive data is requested of not, effectively making the caching mechanism more efficient during login.
Fixes#2131.
After some heavy profiling, it became clear that sending of each message was causing a fetch to get all contacts from status-go. This was incurring a minimum of a 0.03s delay for each fetch, which was causing a bottleneck each time it was called for various operations throughout the codebase.
This code addds a layer of threadsafe caching to the contacts call, such that only the first call to contacts fetching will incur the delay, as well as every fetch after a contacts CUD operation.
Fixes#2143.
Methuselah is the a task manager for long-running tasks. It allows fo registration of workers that will each run in their own thead. Each worker can pass messages to and recieve messages from the main thread.
MailserverWoker was also introduced which moves all mailserver model logic to a MethuselahWorker. All communication to/from the model is done via a MethuselahTask. Results of the task are returned to the main thread by way of `signal_handler`, which calls the QtObject slot specified in the task.
Mailsever also provides a way for the model to emit events inside of the worker. These events are forwarded to the main thread via the `receiveEvent` slot of the `MailserverController`.
Co-authored-by: Michael Bradley, Jr <michaelsbradleyjr@gmail.com>
This was caused by the fact that the canPost property was not exposed from the ChatItem model.
I'm actually not sure why it didn't show an error trying to call a function that doesn't exist
When contract addresses that are not ERC-20 or ERC-721 were input, the token would be allowed to be added and would crash the app.
In addition, when an ERC-20 contract was deployed without a name and symbol, “Invalid ERC-20 address” would appear.
This PR adds error checking from the token detail lookup and reports the error back to the user in the modal. This prevents non-ERC-20/721 contracts from being able to be added to the app and prevents a crash.
Two fake messages are usually added to chat message lists inside a channel or
chat:
- One that imitates a chat identifier
- one that creates a button to fetch older messages
These two fake messages are added so it's ensured they show up at the beginning
of the chat.
The status timeline is also just a list of messages (filtered by a certain message
type), however there's no need to render these fake messages in this scenario.
That's why a `addFakeMessages` flag has been introduced which conditionally adds
those fake messages here: https://github.com/status-im/status-desktop/commit/3f012dbf0#diff-6aa545137319516beb03623bc6a9750e1d14a40c68d8868b5a672320fc4d680aR69
At some point, possibly around here (https://github.com/status-im/status-desktop/commit/8ee5abe57), the fake message for
the fetch more button has been reintroduced as default fake message.
This commit puts it back into the function so that it doesn't show up
inside the timeline view.
refactor: move threadpool task declarations inline with views
Co-authored-by: Michael Bradley Jr. <michaelsbradleyjr@gmail.com>
Co-authored-by: Eric Mastro <eric.mastro@gmail.com>
There was a bug introduced https://github.com/status-im/status-desktop/commit/2ac67f95a where we'd rely on the
possibly resolved public key, which is passed to `generateAlias()`.
The public key is never guaranteed to be an actual key (if resolution fails,
it's a an empty string). Passing an empty string to `generateAlias()` causes
`status-go` to crash and we don't handle that error.
This commit ensures that we only attempt to generate an alias when we
indeed have a successfully resolved public key.
Move the remaining stickers spawnAndSend (obtainAvailableStickerPacks) into a threadpool task.
refactor: create a base class for tasks models to inherit from
NOTE: this branch is based off of `experiment/tasks-3` and should be rebased on master once that branch is merged.
The `TaskManager` threadpool is a memory-safe replacement for the `spawnAndSend` operations that are currently causing memory issues in status-desktop.
From a fundamental memory management point of view, `libstatus/settings`, `libstatus/contracts`, and `libstatus/tokens` (custom tokens) have all been converted to `{.threadvar.}`s and `Atomic[bool]`s to maintain the cache and `dirty` flag across threads, respectively, eliminating the need for thread locks and incorrect `{.gcsafe.}` compiler overrides.
The successful [recyclable threadpool experiment from `nim-task-runner`](https://github.com/status-im/nim-task-runner/blob/test/use-cases/test/use_cases/test_sync.nim) using `AsyncChannel[ThreadSafeString]`s was brought over to `status-desktop` and implemented in somewhat of a hardcoded manner, as we knew this would save some time instead of trying to create a fully fleshed out `nim-task-runner` API and build a miraculous macro that may or may not be able to generate the needed API.
The threadpool is started by the `TaskManager` and both the `TaskManager` and the `TaskManager`'s threadpool are started as early as possible in the application lifecycle (in `nim_status_client.nim`). The `TaskManager` creates a thread to run the threadpool. During its initialization, the threadpool then spools up all the threads it will manage and puts them in an idle thread sequence. This is to prevent expensive thread creation and teardown happening during the app's lifetime as it is quite expensive and blocks the main thread. When tasks comes in to the pool, the task is sent to an idle thread, or put in a queue if all threads are busy. The idle thread is moved to the busy thread sequence. When a task is completed, the thread is taken out of the busy threads sequence and moved back in to the sequence of idle threads, effectively recycling it.
The first `spawnAndSend` we were able to change over to the new threadpool was `estimate`, which estimates the gas of a sticker purchase transaction.
From the consumer point of view, the existing `spawnAndSend` to achieve this looks like:
```nim
proc estimate*(self: StickersView, packId: int, address: string, price: string, uuid: string) {.slot.} =
let status_stickers = self.status.stickers
spawnAndSend(self, "setGasEstimate") do:
var success: bool
var estimate = status_stickers.estimateGas(packId, address, price, success)
if not success:
estimate = 325000
let result: tuple[estimate: int, uuid: string] = (estimate, uuid)
Json.encode(result)
```
And the new syntax looks like this:
```nim
proc estimate*(self: StickersView, packId: int, address: string, price: string, uuid: string) {.slot.} =
self.status.taskManager.threadPool.stickers.stickerPackPurchaseGasEstimate(cast[pointer](self.vptr), "setGasEstimate", packId, address, price, uuid)
```
The logic inside the `spawnAndSend` body was moved to [src/status/tasks/stickers.nim](https://github.com/status-im/status-desktop/compare/experiment/tasks-3?expand=1#diff-09e57eef00b0cee5c4abdb9039f948d8372e7003e09e934a9b4c7e9167d47658).
This is just the first migration of `spawnAndSend`, however moving the majority of the remaining `spawnAndSend`s will likely just be an exercise in copy/pasta. There will be one or two that may require a bit more thinking, depending how they rely on data from the model.
Once the `spawnAndSend`s have been converted to the threadpool, we can start implementing the [long-running process from the task runner use case experiments](https://github.com/status-im/nim-task-runner/blob/test/use-cases/test/use_cases/test_long_running.nim).
And finally, we can then implement the [async tasks](https://github.com/status-im/nim-task-runner/blob/test/use-cases/test/use_cases/test_async.nim) if needed.
@michaelsbradleyjr and I spent many hours digging in to the depths of nim's memory management in an attempt to understand it. We have created [a presentation with our task runner experiment findings](https://docs.google.com/presentation/d/1ItCxAfsVTcIoH_E4bgvmHljhbU-tC3T6K2A6ahwAedk/edit?usp=sharing), and @michaelsbradleyjr has spent time [answering questions off the back of that presentation.](https://gist.github.com/michaelsbradleyjr/1eaa9937b3fbb4ffff3fb814f0dd82a9).
We have created a fork of `edn.nim` at `status-im/edn.nim` and we need the PR to be merged and the commit hash updated before we can merge this PR in to `status-desktop`.
We've introduced a regression in https://github.com/status-im/status-desktop/commit/f1e83f74b#diff-f35edd413addd14c1f81816d6b5ee2bcbdf85fa0e3295d324cb78c98e26d4327L364 where we check whether an RPC's `error` is `null`
and its `result` is not `null`.
This breaks the application with an illegal storage access,
as in case of a successful API call, the response will have only a `result` key
(even when it's `null`).
Since we haven't done anything with a possible `error` in the reponse even before
that change was made, this commit removes the `error` check and safe guards around
whether `result` exists.
Fixes#2062
Allow up to 5 images to be dragged and dropped in to one-on-one chats and in the timeline. Can be combined with the existing upload button. The upload file dialog has been changed to allow multiple selections. Drag and dropped images adhere to the following rules, with corresponding validations messages:
- Max 5 image
- Image size must be 0.5 MB or less
- File extension must be one of [".png", ".jpg", ".jpeg", ".heif", "tif", ".tiff"]
Drag and drop and uploaded images are now also deduplicated.
Prior to this commit, communities without an image would render invisible
in the navigation bar of the application. To avoid this, we're now falling
back to our StatusLetterIdenticon component, which renders the first letter
of the community name with the color of the community.
In https://github.com/status-im/status-desktop/commit/31a9d1a6f we've fixed
a bug where a contact's thumbnail hasn't been passed to the `saveContact`
API.
Unfortunately, that fix wasn't memory safe. There are cases when a contact's
`identityImage` is `nil`, resulting in illegal storage access when accessing
a contact's thumbnail.
This commit fixes the issue by safe guarding around `identityImage` possibly
being `nil`.
Turns out message reactions weren't functional in 1 on 1 chats.
Reaction signals come with a `chatId` that they correspond to, which is
then used to determine to channel and message list to apply/remove
the reaction to.
Inside of a 1 on 1 chat, the `chatId` of a reaction coming from the
will always be the pubKey of the the user that receives it.
A user however, usually doesn't store a chat item for her own pubKey
unless it's of type `Profile`.
This results in an illega storage access as reported in #1828
This commit fixes this bug by checking whether the reaction `chatId`
matches the user's `pubKey`. If that's the case, we know that the reaction
corresponds to the reaction's `fromAuthor` chat.
Fixes#1828
This commit introduces the new design and behaviour of the modal
that opens up when starting a new 1-on-1 chat.
Main changes include:
- New search UI/UX functionality of users and ENS resolutions
- Composed view of existing contacts and contacts to be searched
- Ability to add contacts from within the modal
Closes: #1747
This commit does a bunch of things:
- First and foremost, it removes the active channel dependency.
This is needed to have it operate on the correct channel object,
without forcing us to change the active channel (e.g. right-clicking
on a channel item that's not active, will make it active eventually)
- To make that work, this commit changes the `ChannelContextMenu`
to receive a `ChatItemView`, so it can be used for things like determining
what menu options are shown, what members are in a group, whether
someone is admin of a group etc.
- This also required a new `QtProperty` called `contextChannel`.
The reason this is required, is because in some cases, like receiving
members count of groups, we need a complete `ChatItemView` object
as we don't have access to certain APIs otherwise.
- Unfortunately, we can't pass down `activeChannel` every where for that
because sometimes the context menu should not actually operate on
the active channel.
Fixes: #1755
fixes#935
A bug occurs when someone requests a large amount of funds from you since the gas estimation will fail and there isn't a way of handling errors in the source yet.
This PR handles the error appropriatley for both `estimateGas` and `estimateTokenGas` where the response is only converted from hex to int if the RPC call was successful. Otherwise return the error message as the response and let the UI decide how to display it.
Currently the error for gas estimation in transaction bubbles is displayed in a popup however, ive come to realize that 2 popups open instead of one. This is a new bug of which I can't pinpoint the root cause at the moment and have opted to file a separate issue for it.
As reported in #1584 the message that asks users to backup their seed phrase
is shown even when the seed phrase was imported in the first place, implying that
the mnemonic is already backed (it has to come from somewhere, right?).
This commit introduces a new `appSettings` property that is temporarily set to
determine whether or not the backup message should be shown.
It's set only temporarily because we actualy determine whether we want to show the
backup message, by checking if the account's mnemonic is still stored in the settings.
When a backup is done, Status removes the mnemonic from the profile settings.
So in order to get the right behaviour we need to make sure to remove the mnemonic
from the profile settings after the account has logged-in and originated from
an imported seed phrase. This is done by setting the mentioned property.
Closes#1584
This commit makes reactions in the status timeline work.
There are two things prior to this commit that are broken:
1. The logic that opens the reaction context menu always expects
and instance of `chatsView` because it tries to calculate a users
nickname. Such an instance isn't always available in that context, so
the nickname logic has been moved to `appMain` for now, removing that
dependency and therefore making it work in both, the chat view as well
as the status view.
2. While 1) makes the context menu work, it turns out that adding and
removing reactions inside the status timeline is still not working.
The reason for that is, that the reactions component maintains its own
`messageList`, which isn't aware of the fact that reactions for messages
coming from chats of `ChatType.Profile`, need to go into a dedicated
message list for `ChatType.Timeline`.
In other words, reactions are sent and removed from message in messagelists
that don't actually exist.
This commit fixes both of these things by ensuring the message lists
maintained by reactions are timeline aware. Also ensuring updates are
done correctly.
The `messageList` model used for rendering messages gets notified by the
`activeChannelChanged()` signal. That signal is not immediately emitted inside
the timeline when new messages are received.
This causes the underlying view data to be out of sync with the model,
causing UI bugs, such as rendering the `EmptyTimeline` component when in fact,
the timeline is not empty.
To fix this, there are two options:
1. Change the signal from `activeChannelChanged` to `messagePushed` signal, which
is for sure emitted when messages are received
2. Ensure `activeChannelChanged` is emitted when messages are pushed and the
active channel is indeed the timeline
Since the application has been relying on `activeChannelChanged` so far, I decided
to go with option 2 as I'm not sure whether option 1 would introduce other unwanted
side effects.
When the network connection is changed, the sticker packs are cleared and then re-loaded (either loading the offline (installed) sticker packs, or all the sticker packs from the network).
Stickers can be sent while offline, though the sticker images do not load once offline (this is likely a side effect of the bug described below).
There is a known bug in QNetworkAccessManager (https://bugreports.qt.io/browse/QTBUG-55180) that was re-introduced in 5.14.1 that does not allow us to download resources if we go offline then come back online. The workaround employed in this PR manually sets the NetworkAccessible property of QNetworkAccessManager once we have been connected back online. The NetworkAccessible property is marked as obsolete and will be removed in Qt6, so it is something that we need to be aware of when we upgrade. However the hope is that the bug has been fixed.
Close StickersPopup when disconnected from network (so that re-loading of sticker packs doesn't look out of place).
fix: set network status correctly at load
feat: stickers gas estimate async
feat: When network re-connected, any http images that were not properly loaded in an ImageLoader component will automatically be reloaded.
fix: Sticker button loading icon
chore: Bump nimqml and dotherside
NOTE: This PR uses an updated nimqml and dotherside. The respective changes should be merged first, and the commit hash should be bumped in this PR prior to merging. Relevant PRs:
[https://github.com/status-im/dotherside/pull/20](https://github.com/status-im/dotherside/pull/20)
[https://github.com/status-im/nimqml/pull/17](https://github.com/status-im/nimqml/pull/17)
When sending a profile status update, the message has to be sent to
a specific channel that has the id `@PUBKEY`.
This commit introduces a flag that controls whether the message is
sent to the currently active channel, or tot he profile status channel.
The same is done for the `sendImage` API.
Fixes#1377.
Fixes#1479.
Two sites have been added to the whitelist: giphy.com and tenor.com.
`imageUrls` in its entirety has been removed and instead all links are being handle through the message `linkUrls`. This prevents double-handling of urls that may or may not be images.
The logic to automatically show links previews works like this:
1. If the setting "display chat images" is enabled, all links that *contain* ".png", ".jpg", ".jpeg", ".svg", ".gif" will be automatically shown. If the URL doesn't contain the extension, we are not downloading it. This was meant to be somewhat of a security compromise as we do not want to download each and every link posted in a message just to find out its true content type.
2. If the above setting is *disabled*, then we follow the whitelist settings for tenor and giphy. This allows us to preview gifs that do not have a file extension in their url.
feat: bump status-go to the commit that supports the new whitelist (https://github.com/status-im/status-go/pull/2094), and also lets us get link preview data from urls in the whitelist. NOTE: this commit was branched off status-go `develop`, so once it is merged, and we update this PR to the new commit, we will effectively be getting status-go develop changes. We *could* base that status-go PR off of master if it makes things easier.
fix: height on settings update issue
feat: move date/time of message below links
fix: layout issues when changing setting `neverAskAboutUnfurlingAgain`
feat: Add MessageBorder component to aid in showing rounded corners with different radius
Previously, this API would take a flag `oneToOne` and would use it to determine
whether the chat type is going to be `1` or `2`. However, there are many more chat
types, so it's important this API supports all of them.
Since we already have an enum in place, I'm changing this function to take it instead.
In addition, it also gets a `profile` parameter which is needed to implement
the status timeline functionality.
Primary motivator here was that the current `getContacts` APIs requries
a `ContactModel` which isn't always around. In fact, there's actually
no particular reason this APIs has to live on a model object.
However, to not break existing APIs I'm introducing a `getAllContacts`
API that returns all contacts as profiles, just like `contacts.getContacts`
does, without it being dependent on a `ContactModel`.
The same function is then used to add an API for returning all *added*
contacts as profiles.
By default the desktop app uses port 30305, unless a value is specifically set
in environment variable `STATUS_PORT`. For convenience of those developing the
app and running development builds, while simultaneously running production
builds (a.k.a. packaged builds, whether built locally or in CI), have `make
run` invoke `bin/nim_status_client` with `STATUS_PORT=30306`. That value can
still be overriden by manually invoking `make run` with a different value,
e.g. `make STATUS_PORT=30307 run` and `STATUS_PORT=30307 make run` are both
valid and achieve the same effect. NOTE: the port "sticks" in the database
after the first clean run, so when changing ports developers will need to
delete the data dir within their local repository, else the existing database
for dev builds will be stuck using whatever port was used previously. In the
future, we can figure out a means to always update the port setting in the
database just after the login event (but see #1505).
Also, for development builds use an icon (for the running app) that is
orangered (`#ff4500`) instead of the official blue color. This makes it much
easier to select between a running production instance and development instance
when Cmd-Tab'ing (on macOS, or equiv on Linux and Windows) through open
applications. Not all icons displayed at runtime have been changed in this
manner for development builds, just the main application icon, and that seems
to be sufficient to achieve the desired effect; though in the future we could
do similar for notification icon, menu bar icon, etc.
When dealing with Timeline and Profile chat data, the `HEAD~1` would break
because we're trying to access `ChatType(4)` inside our `toChat` API.
To fix this issue, we have to make `ChatType` aware of `4` and `5` which are
`Profile` and `Timeline` respectively.
Pascal Precht
Jonathan Rainville
Richard Ramos
Eric Mastro
Andrei Smirnov
Sale Djenic
Iuri Matias
Michael Bradley, Jr
staked-smart-ace
ace-smart
Malik Al-Jabr