Commit Graph

32 Commits

Author SHA1 Message Date
Sale Djenic eb41dbe175 refactor(@desktop/general): repo cleaning
- all unused/unnecessary files remove
- `status-lib` references updated due to cleaning on that side
- necessary submodules added (those removed from status lib)
2022-02-01 11:52:33 +01:00
Patryk Osmaczko ee462ea178 fix(@desktop/input): deploy Qt plugin to support fcitx
Qt provides support for various input methods through plugins.
Since the fcitx plugin is not delivered with Qt, it needs to be
built and deployed by us.

Fixes: #4436
2022-01-26 18:11:39 +01:00
Richard Ramos 70c1095b60 refactor: creating module for bookmarks and provider 2021-11-05 11:02:45 -04:00
Richard Ramos 5c937a28a3 chore: remove status-go from desktop 2021-09-29 14:50:09 -04:00
B.Melnik 67ca89483d feat(spellchecking): add dictionaries as submodule
Closes: #3449
2021-09-17 12:57:28 -04:00
Richard Ramos 58c50a9cf9 refactor: removed submodules 2021-09-10 11:56:27 -04:00
Richard Ramos 55c48d65bd fix: status lib module name 2021-09-09 14:35:51 -04:00
Richard Ramos 32049aa928 refactor: extract status to separate repository 2021-09-08 15:52:43 -04:00
Richard Ramos db3b7ecfd9 feat: Version Updating
Fixes #1290
2021-08-24 16:56:55 -04:00
Pascal Precht a53a32c5c0 chore: remove wrong git submodule
As mentioned in https://github.com/status-im/status-desktop/pull/2489/files#r626020553
2021-05-04 15:40:31 -04:00
Pascal Precht 7329522a28 chore: add StatusQ as dependency
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.
2021-05-04 14:42:28 -04:00
Michael Bradley, Jr c03a086c01 feat: command-line option can be used to specify app's data directory
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
2021-04-26 09:40:58 -05:00
Eric Mastro 66912fd811 feat: introduce Task Manager threadpool
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`.
2021-03-18 13:15:05 -04:00
Michael Bradley, Jr c4e786bae3 build: add vendor/nim-status-go submodule 2021-03-16 16:37:27 -04:00
Michael Bradley, Jr 470d2e5a17 build: remove vendor/nim-status submodule 2021-03-16 16:37:27 -04:00
Richard Ramos e8183f3a9f feat: use base32 + status infura ipfs for ens contenthash 2020-10-20 14:42:36 -04:00
emizzle e58f5b03eb refactor: make event emitter threadsafe 2020-10-16 10:45:24 -04:00
emizzle 078e9758f0 refactor: use nim-web3 library
Use nim-web3 library and remove internal encoding funcs that were copied from nim-web3.

Remove all instances of EthAddress (and therefore eth/common/eth_types imports)
2020-09-29 13:28:08 -04:00
Richard Ramos 75cb28b24d adding missing deps 2020-09-04 15:57:29 -04:00
Richard Ramos 74a38c671d feat: use nim-status instead of libstatus 2020-07-17 12:59:20 -04:00
Michael Bradley, Jr 4291754283 fix: add vendor/edn.nim to gitmodules 2020-07-14 16:47:20 -05:00
Richard Ramos 637484bd79 feat: show qr codes 2020-06-23 18:52:54 -04:00
Ștefan Talpalaru 150f38b87d remove vendor/nim-nat-traversal
and fix/hide some warnings
2020-06-23 07:37:17 -04:00
Jonathan Rainville eff29af548 feat: get collectibles from the contracts and their respective apis
With collaborative work from @emizzle
2020-06-18 10:55:48 -04:00
emizzle 87c603097e feat: Decode sticker hashes
Decode multihash content identifier (CID) using `libp2p` libraries. Makes some assumptions that we only handle `ipfs-ns` codec hashes and that the sticker hash starts with `e3xxxxyy`, where xxxx is essentially ignore and yy indicates the cid codec.
2020-06-10 14:52:45 -04:00
Ștefan Talpalaru 24505c9b0f .gitmodules: fix URLs so `make github-ssh` works as intended 2020-05-29 12:31:00 -04:00
Pascal Precht 985b5d93d0 fix(ui/wallet): don't require password to be entered as hashed hex 2020-05-21 19:50:58 -04:00
emizzle dafd11fbc0 feat: onboarding generate new account
Generates 5 random accounts with identicons, allows user to enter password, then stores the account and logs in to the statusgo node.

Add EventEmitter that notifies nim_status_client.nim once node has started and is logged in (likely needs some refactoring to include the eventemitter in the base controller class).

Add QML StateMachine for the onboarding view.

Add nimcrytpo, uuids, eventemitter, isaac dependencies via submodules.

Add button to Intro view to randomly gen account.
2020-05-21 19:33:14 -04:00
Richard Ramos 1a92cda0d9 feat: add nim-chronicles 2020-05-21 15:16:24 -04:00
Richard Ramos a80a6c623b fix: signal handler integration with status-go 2020-05-18 11:42:50 -04:00
Richard Ramos ce41388a51 AppImg packaging 2020-05-15 17:18:20 -04:00
Richard Ramos c1d1b60f46 Adding nimbus-build-system 2020-05-15 17:18:20 -04:00