The standard approach on Darwin is to keen applications running when the
window is closed. Clicking the apps icon again in the doc should bring
back the application window.
This changeset refactors things to handle this. It will keep Zap and lnd
running in the background when the main application window is closed.
Quitting the app will stop both the app and lnd.
Fix#586Fix#601
`main.dev.js` was hard to follow and understand the code flow. It housed
code to handle quite a few distinct things. This is a fairly substantial
refactor of the application startup code in which we:
A new `Neutrino` class has been created with 2 public methods. `start`
and `stop`. `start` will launch a new `lnd` process whilst `stop` will
stop it. This class extends the `EventEmitter` class and emits the
following events based on activity detected from the lnd log output.
- `grpc-proxy-started` - gRPC started
- `wallet-opened` Wallet opened
- `fully-synced` - lnd is all caught up to the blockchain
- `got-block-height` - got updated block height
A new `ZapController` class has been created which houses all of the
logic for intraprocess communication between the main and renderer
processes.
Previously we had several `setInterval` loops that were checking every
second to see if the application status has changed and trigging the
appropriate action if so. This was pretty hard to follow has been
replaced here with more extensive use of promises. This enables us to
act instantly to relevant changes rather than waiting up to 1 second
for the next interval to fire.
Now, the only stuff that lives in `main.dev.js` now is the top level
`app` listeners, which calls out the other parts mentioned above to
bootstrap the application.
Wait until the `dom-ready` event has fired before opening up the
devtools window. This prevents the following error message showing up
multiple times when the app starts in dev mode:
> Extension server error: Operation failed: : has no execution context
See https://github.com/electron/electron/issues/12438Fix#499
Use `HtmlWebpackPlugin` to generate our final html file so that we can
remove our inline scripts and insert them dynamically based on our
webpack config.
This enables easy access to all lnd settings for development, and is a step
toward relying on an external configuration file that will be accessible to
users for whom the code is not.
Use debug-logger to provide a more comprehensive and flexible logging
solution. Use two separate log handlers to provide separation between
electron and and lnd logs.
The onboarding settings are only relevant if the user wants to connect to a
remote LND or have Zap run LND. If the LND is already running locally, the user
is capable of separately configuring it.
This does not support the case of connecting to a remote LND while running LND
locally, but I can't think of a reason why someone would do such a thing. In
such a case, they could quit LND, start Zap, then re-start LND.
Tom Kirkpatrick
Ben Woosley
Jack Mallers