Remove more words (#12852)
* remove 'basically' from docs * remove 'simply' from docs * remove most uses of 'just' from docs
This commit is contained in:
parent
86d023b02f
commit
4d078fdb03
32 changed files with 51 additions and 52 deletions
|
@ -43,7 +43,7 @@ A major update came with version `v1.0.0`. If you're not yet using this version,
|
|||
|
||||
In order to keep Electron small (file size) and sustainable (the spread of dependencies and APIs) the project limits the scope of the core project.
|
||||
|
||||
For instance, Electron uses just the rendering library from Chromium rather than all of Chromium. This makes it easier to upgrade Chromium but also means some browser features found in Google Chrome do not exist in Electron.
|
||||
For instance, Electron uses Chromium's rendering library rather than all of Chromium. This makes it easier to upgrade Chromium but also means some browser features found in Google Chrome do not exist in Electron.
|
||||
|
||||
New features added to Electron should primarily be native APIs. If a feature can be its own Node.js module, it probably should be. See the [Electron tools built by the community](https://electronjs.org/community).
|
||||
|
||||
|
|
|
@ -119,7 +119,7 @@ install it as a dependency:
|
|||
npm install --save aws-sdk
|
||||
```
|
||||
|
||||
Then, in your Electron app, simply require and use the module as if you were
|
||||
Then, in your Electron app, require and use the module as if you were
|
||||
building a Node.js application:
|
||||
|
||||
```javascript
|
||||
|
|
|
@ -25,7 +25,7 @@ of the most powerful utilities in any Electron Developer's tool belt.
|
|||
|
||||
## Main Process
|
||||
|
||||
Debugging the main process is a bit trickier, since you cannot simply open
|
||||
Debugging the main process is a bit trickier, since you cannot open
|
||||
developer tools for them. The Chromium Developer Tools can [be used
|
||||
to debug Electron's main process][node-inspect] thanks to a closer collaboration
|
||||
between Google / Chrome and Node.js, but you might encounter oddities like
|
||||
|
|
|
@ -152,7 +152,7 @@ we appreciate your help.
|
|||
* `ELECTRON_S3_ACCESS_KEY`, `ELECTRON_S3_BUCKET`, `ELECTRON_S3_SECRET_KEY` -
|
||||
the place where you'll upload node.js headers as well as symbols
|
||||
* `ELECTRON_RELEASE` - Set to `true` and the upload part will run, leave unset
|
||||
and `surf-build` will just do CI-type checks, appropriate to run for every
|
||||
and `surf-build` will do CI-type checks, appropriate to run for every
|
||||
pull request.
|
||||
* `CI` - Set to `true` or else it will fail
|
||||
* `GITHUB_TOKEN` - set it to the same as `ELECTRON_GITHUB_TOKEN`
|
||||
|
|
|
@ -15,7 +15,7 @@ app.
|
|||
|
||||
## Boilerplate vs CLI
|
||||
|
||||
A boilerplate is simply a starting point - a canvas, so to speak - from which
|
||||
A boilerplate is only a starting point - a canvas, so to speak - from which
|
||||
you build your application. They usually come in the form of a repository you
|
||||
can clone and customize to your heart's content.
|
||||
|
||||
|
@ -54,7 +54,7 @@ You can find more information and documentation in [the repository](https://gith
|
|||
|
||||
## electron-react-boilerplate
|
||||
|
||||
If you don't want any tools but simply a solid boilerplate to build from,
|
||||
If you don't want any tools but only a solid boilerplate to build from,
|
||||
CT Lin's [`electron-react-boilerplate`](https://github.com/chentsulin/electron-react-boilerplate) might be worth
|
||||
a look. It's quite popular in the community and uses `electron-builder`
|
||||
internally.
|
||||
|
|
|
@ -24,7 +24,7 @@ you through the installation.
|
|||
|
||||
Once installed, confirm that everything works as expected. Find the macOS
|
||||
`Terminal` application in your `/Applications/Utilities` folder (or by
|
||||
simply search for the word `Terminal` in Spotlight). Open up `Terminal`
|
||||
searching for the word `Terminal` in Spotlight). Open up `Terminal`
|
||||
or another command line client of your choice and confirm that both `node`
|
||||
and `npm` are available:
|
||||
|
||||
|
@ -57,7 +57,7 @@ select the `Node.js runtime`, `npm package manager`, and `Add to PATH`
|
|||
options.
|
||||
|
||||
Once installed, confirm that everything works as expected. Find the Windows
|
||||
PowerShell by simply opening the Start Menu and typing `PowerShell`. Open
|
||||
PowerShell by opening the Start Menu and typing `PowerShell`. Open
|
||||
up `PowerShell` or another command line client of your choice and confirm that
|
||||
both `node` and `npm` are available:
|
||||
|
||||
|
@ -114,4 +114,4 @@ virtually all code editors and IDEs these days support JavaScript.
|
|||
[node-package]: https://nodejs.org/en/download/package-manager/
|
||||
[atom]: https://atom.io/
|
||||
[code]: https://code.visualstudio.com/
|
||||
[windows-vm]: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines
|
||||
[windows-vm]: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines
|
||||
|
|
|
@ -44,7 +44,7 @@ run the main process. An example of your `package.json` might look like this:
|
|||
```
|
||||
|
||||
__Note__: If the `main` field is not present in `package.json`, Electron will
|
||||
attempt to load an `index.js` (just like Node.js itself). If this was actually
|
||||
attempt to load an `index.js` (as Node.js does). If this was actually
|
||||
a simple Node application, you would add a `start` script that instructs `node`
|
||||
to execute the current package:
|
||||
|
||||
|
@ -101,7 +101,7 @@ const electron = require('electron')
|
|||
|
||||
The `electron` module exposes features in namespaces. As examples, the lifecycle
|
||||
of the application is managed through `electron.app`, windows can be created
|
||||
using the `electron.BrowserWindow` class. A simple `main.js` file might just wait
|
||||
using the `electron.BrowserWindow` class. A simple `main.js` file might wait
|
||||
for the application to be ready and open a window:
|
||||
|
||||
```javascript
|
||||
|
|
|
@ -106,7 +106,7 @@ In almost all cases, these errors are the result of network problems and not
|
|||
actual issues with the `electron` npm package. Errors like `ELIFECYCLE`,
|
||||
`EAI_AGAIN`, `ECONNRESET`, and `ETIMEDOUT` are all indications of such
|
||||
network problems. The best resolution is to try switching networks, or
|
||||
just wait a bit and try installing again.
|
||||
wait a bit and try installing again.
|
||||
|
||||
You can also attempt to download Electron directly from
|
||||
[electron/electron/releases][releases]
|
||||
|
@ -138,4 +138,4 @@ If you need to force a re-download of the asset and the SHASUM file set the
|
|||
[proxy-env]: https://github.com/request/request/tree/f0c4ec061141051988d1216c24936ad2e7d5c45d#controlling-proxy-behaviour-using-environment-variables
|
||||
[electron-download]: https://github.com/electron-userland/electron-download
|
||||
[npm-permissions]: https://docs.npmjs.com/getting-started/fixing-npm-permissions
|
||||
[unsafe-perm]: https://docs.npmjs.com/misc/config#unsafe-perm
|
||||
[unsafe-perm]: https://docs.npmjs.com/misc/config#unsafe-perm
|
||||
|
|
|
@ -45,7 +45,7 @@ main process or the renderer process), use the userland module
|
|||
[electron-windows-notifications](https://github.com/felixrieseberg/electron-windows-notifications),
|
||||
which uses native Node addons to send `ToastNotification` and `TileNotification` objects.
|
||||
|
||||
While notifications including buttons work with just `electron-windows-notifications`,
|
||||
While notifications including buttons work with `electron-windows-notifications`,
|
||||
handling replies requires the use of [`electron-windows-interactive-notifications`](https://github.com/felixrieseberg/electron-windows-interactive-notifications), which
|
||||
helps with registering the required COM components and calling your Electron app with
|
||||
the entered user data.
|
||||
|
|
|
@ -9,7 +9,7 @@ Two modes of rendering can be used and only the dirty area is passed in the
|
|||
`'paint'` event to be more efficient. The rendering can be stopped, continued
|
||||
and the frame rate can be set. The specified frame rate is a top limit value,
|
||||
when there is nothing happening on a webpage, no frames are generated. The
|
||||
maximum frame rate is 60, because above that there is no benefit, just
|
||||
maximum frame rate is 60, because above that there is no benefit, only
|
||||
performance loss.
|
||||
|
||||
**Note:** An offscreen window is always created as a [Frameless Window](../api/frameless-window.md).
|
||||
|
|
|
@ -13,7 +13,7 @@ two documents:
|
|||
* To check out the process architecture, see
|
||||
[Main and Renderer Processes][processes].
|
||||
|
||||
If you just came here to learn about Electron, check out the
|
||||
To learn more about Electron, check out the
|
||||
[official guides][readme].
|
||||
|
||||
[first-app]: ./first-app.md
|
||||
|
|
|
@ -369,8 +369,7 @@ that is not known in advance.
|
|||
The `eval()` method has precisely one mission: To evaluate a series of
|
||||
characters as JavaScript and execute it. It is a required method whenever you
|
||||
need to evaluate code that is not known ahead of time. While legitimate use
|
||||
cases exist, just like any other code generators, `eval()` is difficult to
|
||||
harden.
|
||||
cases exist, like any other code generators, `eval()` is difficult to harden.
|
||||
|
||||
Generally speaking, it is easier to completely disable `eval()` than to make
|
||||
it bulletproof. Thus, if you do not need it, it is a good idea to disable it.
|
||||
|
@ -399,7 +398,7 @@ subsequent resources via `HTTP` is also known as "mixed content".
|
|||
|
||||
### Why?
|
||||
|
||||
Simply put, loading content over `HTTPS` assures the authenticity and integrity
|
||||
Loading content over `HTTPS` assures the authenticity and integrity
|
||||
of the loaded resources while encrypting the traffic itself. See the section on
|
||||
[only displaying secure content](#1-only-load-secure-content) for more details.
|
||||
|
||||
|
|
|
@ -44,7 +44,7 @@ npm install --save-dev electron-installer-snap
|
|||
|
||||
Package the application using [electron-packager][electron-packager] (or a
|
||||
similar tool). Make sure to remove `node_modules` that you don't need in your
|
||||
final application, since any module you don't actually need will just increase
|
||||
final application, since any module you don't actually need will increase
|
||||
your application's size.
|
||||
|
||||
The output should look roughly like this:
|
||||
|
@ -153,8 +153,8 @@ apps:
|
|||
```
|
||||
|
||||
As you can see, the `snapcraft.yaml` instructs the system to launch a file
|
||||
called `electron-launch`. In this example, it simply passes information on
|
||||
to the app's binary:
|
||||
called `electron-launch`. In this example, it passes information on to the
|
||||
app's binary:
|
||||
|
||||
```sh
|
||||
#!/bin/sh
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
# Testing on Headless CI Systems (Travis CI, Jenkins)
|
||||
|
||||
Being based on Chromium, Electron requires a display driver to function.
|
||||
If Chromium can't find a display driver, Electron will simply fail to launch -
|
||||
If Chromium can't find a display driver, Electron will fail to launch -
|
||||
and therefore not executing any of your tests, regardless of how you are running
|
||||
them. Testing Electron-based apps on Travis, Circle, Jenkins or similar Systems
|
||||
requires therefore a little bit of configuration. In essence, we need to use
|
||||
|
@ -20,11 +20,11 @@ for `$DISPLAY`, so no further configuration of your app is required.
|
|||
This step can be automated with Paul Betts's
|
||||
[xvfb-maybe](https://github.com/paulcbetts/xvfb-maybe): Prepend your test
|
||||
commands with `xvfb-maybe` and the little tool will automatically configure
|
||||
xvfb, if required by the current system. On Windows or macOS, it will simply
|
||||
xvfb, if required by the current system. On Windows or macOS, it will
|
||||
do nothing.
|
||||
|
||||
```sh
|
||||
## On Windows or macOS, this just invokes electron-mocha
|
||||
## On Windows or macOS, this invokes electron-mocha
|
||||
## On Linux, if we are in a headless environment, this will be equivalent
|
||||
## to xvfb-run electron-mocha ./test/*.js
|
||||
xvfb-maybe electron-mocha ./test/*.js
|
||||
|
|
|
@ -74,9 +74,9 @@ $ npm install selenium-webdriver
|
|||
|
||||
### 3. Connect to ChromeDriver
|
||||
|
||||
The usage of `selenium-webdriver` with Electron is basically the same with
|
||||
upstream, except that you have to manually specify how to connect chrome driver
|
||||
and where to find Electron's binary:
|
||||
The usage of `selenium-webdriver` with Electron is the same with
|
||||
upstream, except that you have to manually specify how to connect
|
||||
chrome driver and where to find Electron's binary:
|
||||
|
||||
```javascript
|
||||
const webdriver = require('selenium-webdriver')
|
||||
|
@ -160,7 +160,7 @@ client
|
|||
|
||||
## Workflow
|
||||
|
||||
To test your application without rebuilding Electron, simply
|
||||
To test your application without rebuilding Electron,
|
||||
[place](https://github.com/electron/electron/blob/master/docs/tutorial/application-distribution.md)
|
||||
your app source into Electron's resource directory.
|
||||
|
||||
|
|
|
@ -44,7 +44,7 @@ npm install -g electron-windows-store
|
|||
|
||||
Package the application using [electron-packager][electron-packager] (or a similar tool).
|
||||
Make sure to remove `node_modules` that you don't need in your final application, since
|
||||
any module you don't actually need will just increase your application's size.
|
||||
any module you don't actually need will increase your application's size.
|
||||
|
||||
The output should look roughly like this:
|
||||
|
||||
|
@ -108,8 +108,8 @@ In order to run your package, your users will need Windows 10 with the so-called
|
|||
|
||||
In opposition to traditional UWP apps, packaged apps currently need to undergo a
|
||||
manual verification process, for which you can apply [here][centennial-campaigns].
|
||||
In the meantime, all users will be able to just install your package by double-clicking it,
|
||||
so a submission to the store might not be necessary if you're simply looking for an
|
||||
In the meantime, all users will be able to install your package by double-clicking it,
|
||||
so a submission to the store might not be necessary if you're looking for an
|
||||
easier installation method. In managed environments (usually enterprises), the
|
||||
`Add-AppxPackage` [PowerShell Cmdlet can be used to install it in an automated fashion][add-appxpackage].
|
||||
|
||||
|
|
|
@ -58,7 +58,7 @@ app.setUserTasks([
|
|||
])
|
||||
```
|
||||
|
||||
To clean your tasks list, just call `app.setUserTasks` with an empty array:
|
||||
To clean your tasks list, call `app.setUserTasks` with an empty array:
|
||||
|
||||
```javascript
|
||||
const { app } = require('electron')
|
||||
|
@ -78,7 +78,7 @@ particular window's command without restoring or activating the window.
|
|||
|
||||
From MSDN, it's illustrated:
|
||||
|
||||
> This toolbar is simply the familiar standard toolbar common control. It has a
|
||||
> This toolbar is the familiar standard toolbar common control. It has a
|
||||
> maximum of seven buttons. Each button's ID, image, tooltip, and state are defined
|
||||
> in a structure, which is then passed to the taskbar. The application can show,
|
||||
> enable, disable, or hide buttons from the thumbnail toolbar as required by its
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue