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
|
@ -435,7 +435,7 @@ window.onbeforeunload = (e) => {
|
|||
e.returnValue = false // equivalent to `return false` but not recommended
|
||||
}
|
||||
```
|
||||
_**Note**: There is a subtle difference between the behaviors of `window.onbeforeunload = handler` and `window.addEventListener('beforeunload', handler)`. It is recommended to always set the `event.returnValue` explicitly, instead of just returning a value, as the former works more consistently within Electron._
|
||||
_**Note**: There is a subtle difference between the behaviors of `window.onbeforeunload = handler` and `window.addEventListener('beforeunload', handler)`. It is recommended to always set the `event.returnValue` explicitly, instead of only returning a value, as the former works more consistently within Electron._
|
||||
|
||||
#### Event: 'closed'
|
||||
|
||||
|
|
|
@ -175,7 +175,7 @@ Gives the per-module maximal V-logging levels to override the value given by
|
|||
source files `my_module.*` and `foo*.*`.
|
||||
|
||||
Any pattern containing a forward or backward slash will be tested against the
|
||||
whole pathname and not just the module. E.g. `*/foo/bar/*=2` would change the
|
||||
whole pathname and not only the module. E.g. `*/foo/bar/*=2` would change the
|
||||
logging level for all code in the source files under a `foo/bar` directory.
|
||||
|
||||
This switch only works when `--enable-logging` is also passed.
|
||||
|
|
|
@ -37,7 +37,7 @@ be dynamically modified.
|
|||
* `action` String
|
||||
|
||||
Sends the `action` to the first responder of application. This is used for
|
||||
emulating default macOS menu behaviors. Usually you would just use the
|
||||
emulating default macOS menu behaviors. Usually you would use the
|
||||
[`role`](menu-item.md#roles) property of a [`MenuItem`](menu-item.md).
|
||||
|
||||
See the [macOS Cocoa Event Handling Guide](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/10000060i-CH3-SW7)
|
||||
|
|
|
@ -100,7 +100,7 @@ Objects created with `new Notification` have the following instance methods:
|
|||
#### `notification.show()`
|
||||
|
||||
Immediately shows the notification to the user, please note this means unlike the
|
||||
HTML5 Notification implementation, simply instantiating a `new Notification` does
|
||||
HTML5 Notification implementation, instantiating a `new Notification` does
|
||||
not immediately show it to the user, you need to call this method before the OS
|
||||
will display it.
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ do in chromium (i.e. they do not return a [`BrowserWindowProxy`](browser-window-
|
|||
|
||||
## Example
|
||||
|
||||
To create a sandboxed window, simply pass `sandbox: true` to `webPreferences`:
|
||||
To create a sandboxed window, pass `sandbox: true` to `webPreferences`:
|
||||
|
||||
```js
|
||||
let win
|
||||
|
@ -86,7 +86,7 @@ It is not possible to have the OS sandbox active only for some renderers, if
|
|||
`--enable-sandbox` is enabled, normal electron windows cannot be created.
|
||||
|
||||
If you need to mix sandboxed and non-sandboxed renderers in one application,
|
||||
simply omit the `--enable-sandbox` argument. Without this argument, windows
|
||||
omit the `--enable-sandbox` argument. Without this argument, windows
|
||||
created with `sandbox: true` will still have node.js disabled and communicate
|
||||
only via IPC, which by itself is already a gain from security POV.
|
||||
|
||||
|
|
|
@ -17,4 +17,4 @@ following criteria.
|
|||
* App is signed
|
||||
* App has it's `NSUserNotificationAlertStyle` set to `alert` in the `Info.plist`.
|
||||
|
||||
If either of these requirements are not met the button simply won't appear.
|
||||
If either of these requirements are not met the button won't appear.
|
||||
|
|
|
@ -16,7 +16,7 @@ it should be only available in the main process. You need to be familiar with
|
|||
the concept of [main process vs. renderer process](../tutorial/application-architecture.md#main-and-renderer-processes)
|
||||
scripts to be able to use those modules.
|
||||
|
||||
The main process script is just like a normal Node.js script:
|
||||
The main process script is like a normal Node.js script:
|
||||
|
||||
```javascript
|
||||
const {app, BrowserWindow} = require('electron')
|
||||
|
|
|
@ -15,7 +15,7 @@ the following Python modules:
|
|||
|
||||
## macOS SDK
|
||||
|
||||
If you're simply developing Electron and don't plan to redistribute your
|
||||
If you're developing Electron and don't plan to redistribute your
|
||||
custom Electron build, you may skip this section.
|
||||
|
||||
For certain features (e.g. pinch-zoom) to work properly, you must target the
|
||||
|
|
|
@ -143,7 +143,7 @@ Try reinstalling 32bit Node.js.
|
|||
|
||||
### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'
|
||||
|
||||
Simply making that directory [should fix the problem](https://stackoverflow.com/a/25095327/102704):
|
||||
Creating that directory [should fix the problem](https://stackoverflow.com/a/25095327/102704):
|
||||
|
||||
```powershell
|
||||
$ mkdir ~\AppData\Roaming\npm
|
||||
|
|
|
@ -45,7 +45,7 @@ can switch the download address to it via
|
|||
`export LIBCHROMIUMCONTENT_MIRROR=http://7xk3d2.dl1.z0.glb.clouddn.com/`
|
||||
|
||||
If you only want to build Electron quickly for testing or development, you
|
||||
can download just the shared library versions by passing the `--dev` parameter:
|
||||
can download the shared library versions by passing the `--dev` parameter:
|
||||
|
||||
```sh
|
||||
$ ./script/bootstrap.py --dev
|
||||
|
@ -69,7 +69,7 @@ uses `R` and `D` instead. This is because `gyp` randomly crashes if there is
|
|||
only one `Release` or `Debug` build configuration defined, and Electron only has
|
||||
to generate one target at a time as stated above.
|
||||
|
||||
This only affects developers, if you are just building Electron for rebranding
|
||||
This only affects developers, if you are building Electron for rebranding
|
||||
you are not affected.
|
||||
|
||||
## Tests
|
||||
|
@ -95,7 +95,7 @@ $ npm run build && npm test
|
|||
|
||||
You can make the test suite run faster by isolating the specific test or block
|
||||
you're currently working on using Mocha's
|
||||
[exclusive tests](https://mochajs.org/#exclusive-tests) feature. Just append
|
||||
[exclusive tests](https://mochajs.org/#exclusive-tests) feature. Append
|
||||
`.only` to any `describe` or `it` function call:
|
||||
|
||||
```js
|
||||
|
|
|
@ -10,7 +10,7 @@ requests, which will save you and the reviewers' time.
|
|||
You can install `clang-format` and `git-clang-format` via
|
||||
`npm install -g clang-format`.
|
||||
|
||||
To automatically format a file according to Electron C++ code style, simply run
|
||||
To automatically format a file according to Electron C++ code style, run
|
||||
`clang-format -i path/to/electron/file.cc`. It should work on macOS/Linux/Windows.
|
||||
|
||||
The workflow to format your changed code:
|
||||
|
|
|
@ -160,7 +160,7 @@ $ npm run test
|
|||
Make sure the linter does not report any issues and that all tests pass.
|
||||
Please do not submit patches that fail either check.
|
||||
|
||||
If you are updating tests and just want to run a single spec to check it:
|
||||
If you are updating tests and want to run a single spec to check it:
|
||||
|
||||
```sh
|
||||
$ npm run test -match=menu
|
||||
|
|
|
@ -55,7 +55,7 @@ the content layer. For example to implement Pepper API, we need some wiring
|
|||
similar to what official Chrome does. We could have built the relevant
|
||||
sources as a part of [libcc](../glossary.md#libchromiumcontent) but most
|
||||
often we don't require all the features (some tend to be proprietary,
|
||||
analytics stuff) so we just took parts of the code. These could have easily
|
||||
analytics stuff) so we took parts of the code. These could have easily
|
||||
been patches in libcc, but at the time when these were written the goal of
|
||||
libcc was to maintain very minimal patches and chromium_src changes tend to be
|
||||
big ones. Also, note that these patches can never be upstreamed unlike other
|
||||
|
|
|
@ -9,7 +9,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](https://github.com/electron/electron/releases)
|
||||
|
|
|
@ -82,7 +82,7 @@ See https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md
|
|||
|
||||
Native modules (also called [addons] in
|
||||
Node.js) are modules written in C or C++ that can be loaded into Node.js or
|
||||
Electron using the require() function, and used just as if they were an
|
||||
Electron using the require() function, and used as if they were an
|
||||
ordinary Node.js module. They are used primarily to provide an interface
|
||||
between JavaScript running in Node.js and C/C++ libraries.
|
||||
|
||||
|
|
|
@ -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…
Reference in a new issue