chore: disallow shortcut reference links in docs Markdown (#36860)
* chore: disallow shortcut reference links in docs Markdown * docs: clean up shortcut-style links
This commit is contained in:
David Sanders
GitHub
parent
a9e7bb0027
commit
d94f35a8f6
38 changed files with 199 additions and 171 deletions
|
|
@ -55,7 +55,7 @@ will then be your distribution to deliver to users.
|
|||
### With an app source code archive (asar)
|
||||
|
||||
Instead of shipping your app by copying all of its source files, you can
|
||||
package your app into an [asar] archive to improve the performance of reading
|
||||
package your app into an [asar][] archive to improve the performance of reading
|
||||
files on platforms like Windows, if you are not already using a bundler such
|
||||
as Parcel or Webpack.
|
||||
|
||||
|
|
|
|||
|
|
@ -117,9 +117,9 @@ driver.quit()
|
|||
## Using Playwright
|
||||
|
||||
[Microsoft Playwright](https://playwright.dev) is an end-to-end testing framework built
|
||||
using browser-specific remote debugging protocols, similar to the [Puppeteer] headless
|
||||
using browser-specific remote debugging protocols, similar to the [Puppeteer][] headless
|
||||
Node.js API but geared towards end-to-end testing. Playwright has experimental Electron
|
||||
support via Electron's support for the [Chrome DevTools Protocol] (CDP).
|
||||
support via Electron's support for the [Chrome DevTools Protocol][] (CDP).
|
||||
|
||||
### Install dependencies
|
||||
|
||||
|
|
|
|||
|
|
@ -40,9 +40,9 @@ your app isn't doing anything to endanger its users.
|
|||
To start the process, ensure that you fulfill the requirements for signing and
|
||||
notarizing your app:
|
||||
|
||||
1. Enroll in the [Apple Developer Program] (requires an annual fee)
|
||||
2. Download and install [Xcode] - this requires a computer running macOS
|
||||
3. Generate, download, and install [signing certificates]
|
||||
1. Enroll in the [Apple Developer Program][] (requires an annual fee)
|
||||
2. Download and install [Xcode][] - this requires a computer running macOS
|
||||
3. Generate, download, and install [signing certificates][]
|
||||
|
||||
Electron's ecosystem favors configuration and freedom, so there are multiple
|
||||
ways to get your application signed and notarized.
|
||||
|
|
@ -51,8 +51,8 @@ ways to get your application signed and notarized.
|
|||
|
||||
If you're using Electron's favorite build tool, getting your application signed
|
||||
and notarized requires a few additions to your configuration. [Forge](https://electronforge.io) is a
|
||||
collection of the official Electron tools, using [`electron-packager`],
|
||||
[`@electron/osx-sign`], and [`@electron/notarize`] under the hood.
|
||||
collection of the official Electron tools, using [`electron-packager`][],
|
||||
[`@electron/osx-sign`][], and [`@electron/notarize`][] under the hood.
|
||||
|
||||
Detailed instructions on how to configure your application can be found in the
|
||||
[Signing macOS Apps](https://www.electronforge.io/guides/code-signing/code-signing-macos) guide in
|
||||
|
|
@ -61,8 +61,8 @@ the Electron Forge docs.
|
|||
### Using Electron Packager
|
||||
|
||||
If you're not using an integrated build pipeline like Forge, you
|
||||
are likely using [`electron-packager`], which includes [`@electron/osx-sign`] and
|
||||
[`@electron/notarize`].
|
||||
are likely using [`electron-packager`][], which includes [`@electron/osx-sign`][] and
|
||||
[`@electron/notarize`][].
|
||||
|
||||
If you're using Packager's API, you can pass [in configuration that both signs
|
||||
and notarizes your application](https://electron.github.io/electron-packager/main/interfaces/electronpackager.options.html).
|
||||
|
|
@ -82,7 +82,7 @@ packager({
|
|||
|
||||
### Signing Mac App Store applications
|
||||
|
||||
See the [Mac App Store Guide].
|
||||
See the [Mac App Store Guide][].
|
||||
|
||||
## Signing Windows builds
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ Electron Forge is the recommended way to sign your `Squirrel.Windows` and `WiX M
|
|||
|
||||
### Using electron-winstaller (Squirrel.Windows)
|
||||
|
||||
[`electron-winstaller`] is a package that can generate Squirrel.Windows installers for your
|
||||
[`electron-winstaller`][] is a package that can generate Squirrel.Windows installers for your
|
||||
Electron app. This is the tool used under the hood by Electron Forge's
|
||||
[Squirrel.Windows Maker][maker-squirrel]. If you're not using Electron Forge and want to use
|
||||
`electron-winstaller` directly, use the `certificateFile` and `certificatePassword` configuration
|
||||
|
|
@ -135,16 +135,16 @@ try {
|
|||
}
|
||||
```
|
||||
|
||||
For full configuration options, check out the [`electron-winstaller`] repository!
|
||||
For full configuration options, check out the [`electron-winstaller`][] repository!
|
||||
|
||||
### Using electron-wix-msi (WiX MSI)
|
||||
|
||||
[`electron-wix-msi`] is a package that can generate MSI installers for your
|
||||
[`electron-wix-msi`][] is a package that can generate MSI installers for your
|
||||
Electron app. This is the tool used under the hood by Electron Forge's [MSI Maker][maker-msi].
|
||||
|
||||
If you're not using Electron Forge and want to use `electron-wix-msi` directly, use the
|
||||
`certificateFile` and `certificatePassword` configuration options
|
||||
or pass in parameters directly to [SignTool.exe] with the `signWithParams` option.
|
||||
or pass in parameters directly to [SignTool.exe][] with the `signWithParams` option.
|
||||
|
||||
```js {12-13}
|
||||
import { MSICreator } from 'electron-wix-msi'
|
||||
|
|
@ -177,7 +177,7 @@ supportBinaries.forEach(async (binary) => {
|
|||
await msiCreator.compile()
|
||||
```
|
||||
|
||||
For full configuration options, check out the [`electron-wix-msi`] repository!
|
||||
For full configuration options, check out the [`electron-wix-msi`][] repository!
|
||||
|
||||
### Using Electron Builder
|
||||
|
||||
|
|
@ -186,7 +186,7 @@ can find [its documentation here](https://www.electron.build/code-signing).
|
|||
|
||||
### Signing Windows Store applications
|
||||
|
||||
See the [Windows Store Guide].
|
||||
See the [Windows Store Guide][].
|
||||
|
||||
[apple developer program]: https://developer.apple.com/programs/
|
||||
[`@electron/osx-sign`]: https://github.com/electron/osx-sign
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ contextBridge.exposeInMainWorld('myAPI', {
|
|||
|
||||
## Usage with TypeScript
|
||||
|
||||
If you're building your Electron app with TypeScript, you'll want to add types to your APIs exposed over the context bridge. The renderer's `window` object won't have the correct typings unless you extend the types with a [declaration file].
|
||||
If you're building your Electron app with TypeScript, you'll want to add types to your APIs exposed over the context bridge. The renderer's `window` object won't have the correct typings unless you extend the types with a [declaration file][].
|
||||
|
||||
For example, given this `preload.ts` script:
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ from the OS.
|
|||
|
||||
If your app has its own dark mode, you should toggle it on and off in sync with
|
||||
the system's dark mode setting. You can do this by using the
|
||||
[prefers-color-scheme] CSS media query.
|
||||
[prefers-color-scheme][] CSS media query.
|
||||
|
||||
### Manually update your own interfaces
|
||||
|
||||
|
|
|
|||
|
|
@ -36,13 +36,13 @@ guide!).
|
|||
|
||||
| Guide | Description |
|
||||
| :-------------------- | ------------------------------------------------------------------------------------------------------------------- |
|
||||
| [Message ports] | This guide provides some examples of how you might use MessagePorts in your app to communicate different processes. |
|
||||
| [Device access] | Learn how to access the device hardware (Bluetooth, USB, Serial). |
|
||||
| [Keyboard shortcuts] | Configure local and global keyboard shortcuts for your Electron application. |
|
||||
| [Multithreading] | With Web Workers, it is possible to run JavaScript in OS-level threads |
|
||||
| [Offscreen rendering] | Offscreen rendering lets you obtain the content of a BrowserWindow in a bitmap, so it can be rendered anywhere. |
|
||||
| [Spellchecker] | Learn how to use the built-in spellchecker, set languages, etc. |
|
||||
| [Web embeds] | Discover the different ways to embed third-party web content in your application. |
|
||||
| [Message ports][] | This guide provides some examples of how you might use MessagePorts in your app to communicate different processes. |
|
||||
| [Device access][] | Learn how to access the device hardware (Bluetooth, USB, Serial). |
|
||||
| [Keyboard shortcuts][] | Configure local and global keyboard shortcuts for your Electron application. |
|
||||
| [Multithreading][] | With Web Workers, it is possible to run JavaScript in OS-level threads |
|
||||
| [Offscreen rendering][] | Offscreen rendering lets you obtain the content of a BrowserWindow in a bitmap, so it can be rendered anywhere. |
|
||||
| [Spellchecker][] | Learn how to use the built-in spellchecker, set languages, etc. |
|
||||
| [Web embeds][] | Discover the different ways to embed third-party web content in your application. |
|
||||
|
||||
<!-- guide-table-end -->
|
||||
|
||||
|
|
@ -55,3 +55,10 @@ our [Discord server][discord] and let us know!
|
|||
[app]: ../api/app.md
|
||||
[discord]: https://discord.gg/electronjs
|
||||
[fiddle]: https://www.electronjs.org/fiddle
|
||||
[Message ports]: ./message-ports.md
|
||||
[Device access]: ./devices.md
|
||||
[Keyboard shortcuts]: ./keyboard-shortcuts.md
|
||||
[Multithreading]: ./multithreading.md
|
||||
[Offscreen rendering]: ./offscreen-rendering.md
|
||||
[Spellchecker]: ./spellchecker.md
|
||||
[Web embeds]: ./web-embeds.md
|
||||
|
|
|
|||
|
|
@ -6,23 +6,23 @@ a single extensible interface so that anyone can jump right into making Electron
|
|||
|
||||
## Getting started
|
||||
|
||||
The [Electron Forge docs] contain detailed information on taking your application
|
||||
The [Electron Forge docs][] contain detailed information on taking your application
|
||||
from source code to your end users' machines.
|
||||
This includes:
|
||||
|
||||
* Packaging your application [(package)]
|
||||
* Generating executables and installers for each OS [(make)], and,
|
||||
* Publishing these files to online platforms to download [(publish)].
|
||||
* Packaging your application [(package)][]
|
||||
* Generating executables and installers for each OS [(make)][], and,
|
||||
* Publishing these files to online platforms to download [(publish)][].
|
||||
|
||||
For beginners, we recommend following through Electron's [tutorial] to develop, build,
|
||||
For beginners, we recommend following through Electron's [tutorial][] to develop, build,
|
||||
package and publish your first Electron app. If you have already developed an app on your machine
|
||||
and want to start on packaging and distribution, start from [step 5] of the tutorial.
|
||||
and want to start on packaging and distribution, start from [step 5][] of the tutorial.
|
||||
|
||||
## Getting help
|
||||
|
||||
* If you need help with developing your app, our [community Discord server][discord] is a great place
|
||||
to get advice from other Electron app developers.
|
||||
* If you suspect you're running into a bug with Forge, please check the [GitHub issue tracker]
|
||||
* If you suspect you're running into a bug with Forge, please check the [GitHub issue tracker][]
|
||||
to see if any existing issues match your problem. If not, feel free to fill out our bug report
|
||||
template and submit a new issue.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,9 +15,9 @@ experience required.
|
|||
|
||||
## Getting started
|
||||
|
||||
We recommend you to start with the [tutorial], which guides you through the
|
||||
We recommend you to start with the [tutorial][], which guides you through the
|
||||
process of developing an Electron app and distributing it to users.
|
||||
The [examples] and [API documentation] are also good places to browse around
|
||||
The [examples][] and [API documentation][] are also good places to browse around
|
||||
and discover new things.
|
||||
|
||||
## Running examples with Electron Fiddle
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ native API from your UI or triggering changes in your web contents from native m
|
|||
## IPC channels
|
||||
|
||||
In Electron, processes communicate by passing messages through developer-defined "channels"
|
||||
with the [`ipcMain`] and [`ipcRenderer`] modules. These channels are
|
||||
with the [`ipcMain`][] and [`ipcRenderer`][] modules. These channels are
|
||||
**arbitrary** (you can name them anything you want) and **bidirectional** (you can use the
|
||||
same channel name for both modules).
|
||||
|
||||
|
|
@ -25,16 +25,16 @@ you can use as a reference for your app code.
|
|||
## Understanding context-isolated processes
|
||||
|
||||
Before proceeding to implementation details, you should be familiar with the idea of using a
|
||||
[preload script] to import Node.js and Electron modules in a context-isolated renderer process.
|
||||
[preload script][] to import Node.js and Electron modules in a context-isolated renderer process.
|
||||
|
||||
* For a full overview of Electron's process model, you can read the [process model docs].
|
||||
* For a full overview of Electron's process model, you can read the [process model docs][].
|
||||
* For a primer into exposing APIs from your preload script using the `contextBridge` module, check
|
||||
out the [context isolation tutorial].
|
||||
out the [context isolation tutorial][].
|
||||
|
||||
## Pattern 1: Renderer to main (one-way)
|
||||
|
||||
To fire a one-way IPC message from a renderer process to the main process, you can use the
|
||||
[`ipcRenderer.send`] API to send a message that is then received by the [`ipcMain.on`] API.
|
||||
[`ipcRenderer.send`][] API to send a message that is then received by the [`ipcMain.on`][] API.
|
||||
|
||||
You usually use this pattern to call a main process API from your web contents. We'll demonstrate
|
||||
this pattern by creating a simple app that can programmatically change its window title.
|
||||
|
|
@ -78,7 +78,7 @@ app.whenReady().then(() => {
|
|||
//...
|
||||
```
|
||||
|
||||
The above `handleSetTitle` callback has two parameters: an [IpcMainEvent] structure and a
|
||||
The above `handleSetTitle` callback has two parameters: an [IpcMainEvent][] structure and a
|
||||
`title` string. Whenever a message comes through the `set-title` channel, this function will
|
||||
find the BrowserWindow instance attached to the message sender and use the `win.setTitle`
|
||||
API on it.
|
||||
|
|
@ -108,7 +108,7 @@ At this point, you'll be able to use the `window.electronAPI.setTitle()` functio
|
|||
process.
|
||||
|
||||
:::caution Security warning
|
||||
We don't directly expose the whole `ipcRenderer.send` API for [security reasons]. Make sure to
|
||||
We don't directly expose the whole `ipcRenderer.send` API for [security reasons][]. Make sure to
|
||||
limit the renderer's access to Electron APIs as much as possible.
|
||||
:::
|
||||
|
||||
|
|
@ -153,8 +153,8 @@ to your BrowserWindow title!
|
|||
## Pattern 2: Renderer to main (two-way)
|
||||
|
||||
A common application for two-way IPC is calling a main process module from your renderer process
|
||||
code and waiting for a result. This can be done by using [`ipcRenderer.invoke`] paired with
|
||||
[`ipcMain.handle`].
|
||||
code and waiting for a result. This can be done by using [`ipcRenderer.invoke`][] paired with
|
||||
[`ipcMain.handle`][].
|
||||
|
||||
In the following example, we'll be opening a native file dialog from the renderer process and
|
||||
returning the selected file's path.
|
||||
|
|
@ -236,7 +236,7 @@ contextBridge.exposeInMainWorld('electronAPI', {
|
|||
```
|
||||
|
||||
:::caution Security warning
|
||||
We don't directly expose the whole `ipcRenderer.invoke` API for [security reasons]. Make sure to
|
||||
We don't directly expose the whole `ipcRenderer.invoke` API for [security reasons][]. Make sure to
|
||||
limit the renderer's access to Electron APIs as much as possible.
|
||||
:::
|
||||
|
||||
|
|
@ -359,7 +359,7 @@ renderer process until a reply is received.
|
|||
|
||||
When sending a message from the main process to a renderer process, you need to specify which
|
||||
renderer is receiving the message. Messages need to be sent to a renderer process
|
||||
via its [`WebContents`] instance. This WebContents instance contains a [`send`][webcontents-send] method
|
||||
via its [`WebContents`][] instance. This WebContents instance contains a [`send`][webcontents-send] method
|
||||
that can be used in the same way as `ipcRenderer.send`.
|
||||
|
||||
To demonstrate this pattern, we'll be building a number counter controlled by the native operating
|
||||
|
|
@ -440,7 +440,7 @@ After loading the preload script, your renderer process should have access to th
|
|||
`window.electronAPI.onUpdateCounter()` listener function.
|
||||
|
||||
:::caution Security warning
|
||||
We don't directly expose the whole `ipcRenderer.on` API for [security reasons]. Make sure to
|
||||
We don't directly expose the whole `ipcRenderer.on` API for [security reasons][]. Make sure to
|
||||
limit the renderer's access to Electron APIs as much as possible.
|
||||
:::
|
||||
|
||||
|
|
@ -540,7 +540,7 @@ and `ipcRenderer` modules. To achieve this, you have two options:
|
|||
|
||||
* Use the main process as a message broker between renderers. This would involve sending a message
|
||||
from one renderer to the main process, which would forward the message to the other renderer.
|
||||
* Pass a [MessagePort] from the main process to both renderers. This will allow direct communication
|
||||
* Pass a [MessagePort][] from the main process to both renderers. This will allow direct communication
|
||||
between renderers after the initial setup.
|
||||
|
||||
## Object serialization
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ for your Electron application.
|
|||
### Local Shortcuts
|
||||
|
||||
Local keyboard shortcuts are triggered only when the application is focused.
|
||||
To configure a local keyboard shortcut, you need to specify an [`accelerator`]
|
||||
property when creating a [MenuItem] within the [Menu] module.
|
||||
To configure a local keyboard shortcut, you need to specify an [`accelerator`][]
|
||||
property when creating a [MenuItem][] within the [Menu][] module.
|
||||
|
||||
Starting with a working application from the
|
||||
[Quick Start Guide](quick-start.md), update the `main.js` file with the
|
||||
|
|
@ -48,7 +48,7 @@ generated after triggering the `click` event: "Electron rocks!".
|
|||
|
||||
### Global Shortcuts
|
||||
|
||||
To configure a global keyboard shortcut, you need to use the [globalShortcut]
|
||||
To configure a global keyboard shortcut, you need to use the [globalShortcut][]
|
||||
module to detect keyboard events even when the application does not have
|
||||
keyboard focus.
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ you will see that Electron loves global shortcuts!
|
|||
|
||||
#### Using web APIs
|
||||
|
||||
If you want to handle keyboard shortcuts within a [BrowserWindow], you can
|
||||
If you want to handle keyboard shortcuts within a [BrowserWindow][], you can
|
||||
listen for the `keyup` and `keydown` [DOM events][dom-events] inside the
|
||||
renderer process using the [addEventListener() API][addEventListener-api].
|
||||
|
||||
|
|
@ -128,7 +128,7 @@ see that this key combination was successfully intercepted.
|
|||
#### Using third-party libraries
|
||||
|
||||
If you don't want to do manual shortcut parsing, there are libraries that do
|
||||
advanced key detection, such as [mousetrap]. Below are examples of usage of the
|
||||
advanced key detection, such as [mousetrap][]. Below are examples of usage of the
|
||||
`mousetrap` running in the Renderer process:
|
||||
|
||||
```js
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ This guide provides information on:
|
|||
To sign Electron apps, the following tools must be installed first:
|
||||
|
||||
* Xcode 11 or above.
|
||||
* The [@electron/osx-sign] npm module.
|
||||
* The [@electron/osx-sign][] npm module.
|
||||
|
||||
You also have to register an Apple Developer account and join the
|
||||
[Apple Developer Program][developer-program].
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ An example demonstrating how you can create a file on the fly to be dragged out
|
|||
|
||||
### Preload.js
|
||||
|
||||
In `preload.js` use the [`contextBridge`] to inject a method `window.electron.startDrag(...)` that will send an IPC message to the main process.
|
||||
In `preload.js` use the [`contextBridge`][] to inject a method `window.electron.startDrag(...)` that will send an IPC message to the main process.
|
||||
|
||||
```js
|
||||
const { contextBridge, ipcRenderer } = require('electron')
|
||||
|
|
@ -41,7 +41,7 @@ Add a draggable element to `index.html`, and reference your renderer script:
|
|||
|
||||
### Renderer.js
|
||||
|
||||
In `renderer.js` set up the renderer process to handle drag events by calling the method you added via the [`contextBridge`] above.
|
||||
In `renderer.js` set up the renderer process to handle drag events by calling the method you added via the [`contextBridge`][] above.
|
||||
|
||||
```javascript
|
||||
document.getElementById('drag').ondragstart = (event) => {
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ it also meant that one website crashing or hanging would affect the entire brows
|
|||
To solve this problem, the Chrome team decided that each tab would render in its own
|
||||
process, limiting the harm that buggy or malicious code on a web page could cause to
|
||||
the app as a whole. A single browser process then controls these processes, as well
|
||||
as the application lifecycle as a whole. This diagram below from the [Chrome Comic]
|
||||
as the application lifecycle as a whole. This diagram below from the [Chrome Comic][]
|
||||
visualizes this model:
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ continuing, we recommend the following resources:
|
|||
|
||||
### Code editor
|
||||
|
||||
You will need a text editor to write your code. We recommend using [Visual Studio Code],
|
||||
You will need a text editor to write your code. We recommend using [Visual Studio Code][],
|
||||
although you can choose whichever one you prefer.
|
||||
|
||||
### Command line
|
||||
|
|
@ -73,8 +73,8 @@ on in the tutorial. Therefore, we'll require you to:
|
|||
- [Create a GitHub account](https://github.com/join)
|
||||
- [Install Git](https://github.com/git-guides/install-git)
|
||||
|
||||
If you're unfamiliar with how Git works, we recommend reading GitHub's [Git guides]. You can also
|
||||
use the [GitHub Desktop] app if you prefer using a visual interface over the command line.
|
||||
If you're unfamiliar with how Git works, we recommend reading GitHub's [Git guides][]. You can also
|
||||
use the [GitHub Desktop][] app if you prefer using a visual interface over the command line.
|
||||
|
||||
We recommend that you create a local Git repository and publish it to GitHub before starting
|
||||
the tutorial, and commit your code after every step.
|
||||
|
|
@ -96,8 +96,8 @@ use the latest long-term support (LTS) version.
|
|||
|
||||
Please install Node.js using pre-built installers for your platform.
|
||||
You may encounter incompatibility issues with different development tools otherwise.
|
||||
If you are using macOS, we recommend using a package manager like [Homebrew] or
|
||||
[nvm] to avoid any directory permission issues.
|
||||
If you are using macOS, we recommend using a package manager like [Homebrew][] or
|
||||
[nvm][] to avoid any directory permission issues.
|
||||
|
||||
:::
|
||||
|
||||
|
|
@ -120,8 +120,8 @@ comes bundled with its own Node.js runtime. This means that your end users do no
|
|||
need to install Node.js themselves as a prerequisite to running your app.
|
||||
|
||||
To check which version of Node.js is running in your app, you can access the global
|
||||
[`process.versions`] variable in the main process or preload script. You can also reference
|
||||
the list of versions in the [electron/releases] repository.
|
||||
[`process.versions`][] variable in the main process or preload script. You can also reference
|
||||
the list of versions in the [electron/releases][] repository.
|
||||
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ console.log(`Hello from Electron 👋`)
|
|||
```
|
||||
|
||||
Because Electron's main process is a Node.js runtime, you can execute arbitrary Node.js code
|
||||
with the `electron` command (you can even use it as a [REPL]). To execute this script,
|
||||
with the `electron` command (you can even use it as a [REPL][]). To execute this script,
|
||||
add `electron .` to the `start` command in the [`scripts`][package-scripts]
|
||||
field of your package.json. This command will tell the Electron executable to look for the main
|
||||
script in the current directory and run it in dev mode.
|
||||
|
|
@ -258,7 +258,7 @@ app.whenReady().then(() => {
|
|||
})
|
||||
```
|
||||
|
||||
Many of Electron's core modules are Node.js [event emitters] that adhere to Node's asynchronous
|
||||
Many of Electron's core modules are Node.js [event emitters][] that adhere to Node's asynchronous
|
||||
event-driven architecture. The app module is one of these emitters.
|
||||
|
||||
In Electron, BrowserWindows can only be created after the app module's [`ready`][app-ready] event
|
||||
|
|
@ -288,7 +288,7 @@ open a window that displays your web page!
|
|||
Each web page your app displays in a window will run in a separate process called a
|
||||
**renderer** process (or simply _renderer_ for short). Renderer processes have access
|
||||
to the same JavaScript APIs and tooling you use for typical front-end web
|
||||
development, such as using [webpack] to bundle and minify your code or [React][react]
|
||||
development, such as using [webpack][] to bundle and minify your code or [React][react]
|
||||
to build your user interfaces.
|
||||
|
||||
## Managing your app's window lifecycle
|
||||
|
|
@ -403,7 +403,7 @@ What we have done in the `launch.json` file is to create 3 configurations:
|
|||
that creates the process, we have to "attach" to it (`"request": "attach"`) instead of
|
||||
creating a new one.
|
||||
The renderer process is a web one, so the debugger we have to use is `chrome`.
|
||||
- `Main + renderer` is a [compound task] that executes the previous ones simultaneously.
|
||||
- `Main + renderer` is a [compound task][] that executes the previous ones simultaneously.
|
||||
|
||||
:::caution
|
||||
|
||||
|
|
@ -419,7 +419,7 @@ in development mode.
|
|||
|
||||
If you want to dig deeper in the debugging area, the following guides provide more information:
|
||||
|
||||
- [Application Debugging]
|
||||
- [Application Debugging][]
|
||||
- [DevTools Extensions][devtools extension]
|
||||
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ For more information, check out the [Process Sandboxing](./sandbox.md) guide.
|
|||
|
||||
Preload scripts are injected before a web page loads in the renderer,
|
||||
similar to a Chrome extension's [content scripts][content-script]. To add features to your renderer
|
||||
that require privileged access, you can define [global] objects through the
|
||||
that require privileged access, you can define [global][] objects through the
|
||||
[contextBridge][contextbridge] API.
|
||||
|
||||
To demonstrate this concept, you will create a preload script that exposes your app's
|
||||
|
|
@ -115,7 +115,7 @@ There are two Node.js concepts that are used here:
|
|||
|
||||
At this point, the renderer has access to the `versions` global, so let's display that
|
||||
information in the window. This variable can be accessed via `window.versions` or simply
|
||||
`versions`. Create a `renderer.js` script that uses the [`document.getElementById`]
|
||||
`versions`. Create a `renderer.js` script that uses the [`document.getElementById`][]
|
||||
DOM API to replace the displayed text for the HTML element with `info` as its `id` property.
|
||||
|
||||
```js title="renderer.js"
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ and deeper operating system integrations. To get started, check out the
|
|||
|
||||
:::note Let us know if something is missing!
|
||||
|
||||
If you can't find what you are looking for, please let us know on [GitHub] or in
|
||||
If you can't find what you are looking for, please let us know on [GitHub][] or in
|
||||
our [Discord server][discord]!
|
||||
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ This is **part 5** of the Electron tutorial.
|
|||
## Learning goals
|
||||
|
||||
In this part of the tutorial, we'll be going over the basics of packaging and distributing
|
||||
your app with [Electron Forge].
|
||||
your app with [Electron Forge][].
|
||||
|
||||
## Using Electron Forge
|
||||
|
||||
|
|
@ -35,8 +35,8 @@ as a **distributable**). Distributables can be either installers (e.g. MSI on Wi
|
|||
portable executable files (e.g. `.app` on macOS).
|
||||
|
||||
Electron Forge is an all-in-one tool that handles the packaging and distribution of Electron
|
||||
apps. Under the hood, it combines a lot of existing Electron tools (e.g. [`electron-packager`],
|
||||
[`@electron/osx-sign`], [`electron-winstaller`], etc.) into a single interface so you do not
|
||||
apps. Under the hood, it combines a lot of existing Electron tools (e.g. [`electron-packager`][],
|
||||
[`@electron/osx-sign`][], [`electron-winstaller`][], etc.) into a single interface so you do not
|
||||
have to worry about wiring them all together.
|
||||
|
||||
### Importing your project into Forge
|
||||
|
|
@ -65,7 +65,7 @@ to your `package.json` file.
|
|||
:::info CLI documentation
|
||||
|
||||
For more information on `make` and other Forge APIs, check out
|
||||
the [Electron Forge CLI documentation].
|
||||
the [Electron Forge CLI documentation][].
|
||||
|
||||
:::
|
||||
|
||||
|
|
@ -106,21 +106,21 @@ created your first bundled Electron application.
|
|||
:::tip Distributable formats
|
||||
|
||||
Electron Forge can be configured to create distributables in different OS-specific formats
|
||||
(e.g. DMG, deb, MSI, etc.). See Forge's [Makers] documentation for all configuration options.
|
||||
(e.g. DMG, deb, MSI, etc.). See Forge's [Makers][] documentation for all configuration options.
|
||||
|
||||
:::
|
||||
|
||||
:::tip Creating and adding application icons
|
||||
|
||||
Setting custom application icons requires a few additions to your config.
|
||||
Check out [Forge's icon tutorial] for more information.
|
||||
Check out [Forge's icon tutorial][] for more information.
|
||||
|
||||
:::
|
||||
|
||||
:::info Packaging without Electron Forge
|
||||
|
||||
If you want to manually package your code, or if you're just interested understanding the
|
||||
mechanics behind packaging an Electron app, check out the full [Application Packaging]
|
||||
mechanics behind packaging an Electron app, check out the full [Application Packaging][]
|
||||
documentation.
|
||||
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ at [https://update.electronjs.org](https://update.electronjs.org). Its requireme
|
|||
|
||||
- Your app runs on macOS or Windows
|
||||
- Your app has a public GitHub repository
|
||||
- Builds are published to [GitHub releases]
|
||||
- Builds are published to [GitHub releases][]
|
||||
- Builds are [code signed][code-signed]
|
||||
|
||||
At this point, we'll assume that you have already pushed all your
|
||||
|
|
@ -47,7 +47,7 @@ you need to keep your code repository private, please refer to our
|
|||
|
||||
## Publishing a GitHub release
|
||||
|
||||
Electron Forge has [Publisher] plugins that can automate the distribution
|
||||
Electron Forge has [Publisher][] plugins that can automate the distribution
|
||||
of your packaged application to various sources. In this tutorial, we will
|
||||
be using the GitHub Publisher, which will allow us to publish
|
||||
our code to GitHub releases.
|
||||
|
|
@ -65,7 +65,7 @@ with the `public_repo` scope, which gives write access to your public repositori
|
|||
|
||||
#### Installing the module
|
||||
|
||||
Forge's [GitHub Publisher] is a plugin that
|
||||
Forge's [GitHub Publisher][] is a plugin that
|
||||
needs to be installed in your project's `devDependencies`:
|
||||
|
||||
```sh npm2yarn
|
||||
|
|
@ -76,7 +76,7 @@ npm install --save-dev @electron-forge/publisher-github
|
|||
|
||||
Once you have it installed, you need to set it up in your Forge
|
||||
configuration. A full list of options is documented in the Forge's
|
||||
[`PublisherGitHubConfig`] API docs.
|
||||
[`PublisherGitHubConfig`][] API docs.
|
||||
|
||||
```js title='forge.config.js'
|
||||
module.exports = {
|
||||
|
|
@ -114,7 +114,7 @@ variable.
|
|||
|
||||
### Running the publish command
|
||||
|
||||
Add Forge's [publish command] to your npm scripts.
|
||||
Add Forge's [publish command][] to your npm scripts.
|
||||
|
||||
```json {6} title='package.json'
|
||||
//...
|
||||
|
|
@ -155,8 +155,8 @@ Publishing locally can be painful, especially because you can only create distri
|
|||
for your host operating system (i.e. you can't publish a Window `.exe` file from macOS).
|
||||
|
||||
A solution for this would be to publish your app via automation workflows
|
||||
such as [GitHub Actions], which can run tasks in the
|
||||
cloud on Ubuntu, macOS, and Windows. This is the exact approach taken by [Electron Fiddle].
|
||||
such as [GitHub Actions][], which can run tasks in the
|
||||
cloud on Ubuntu, macOS, and Windows. This is the exact approach taken by [Electron Fiddle][].
|
||||
You can refer to Fiddle's [Build and Release pipeline][fiddle-build]
|
||||
and [Forge configuration][fiddle-forge-config]
|
||||
for more details.
|
||||
|
|
@ -165,7 +165,7 @@ for more details.
|
|||
|
||||
Now that we have a functional release system via GitHub releases, we now need to tell our
|
||||
Electron app to download an update whenever a new release is out. Electron apps do this
|
||||
via the [autoUpdater] module, which reads from an update server feed to check if a new version
|
||||
via the [autoUpdater][] module, which reads from an update server feed to check if a new version
|
||||
is available for download.
|
||||
|
||||
The update.electronjs.org service provides an updater-compatible feed. For example, Electron
|
||||
|
|
@ -175,7 +175,7 @@ to see if a newer GitHub release is available.
|
|||
After your release is published to GitHub, the update.electronjs.org service should work
|
||||
for your application. The only step left is to configure the feed with the autoUpdater module.
|
||||
|
||||
To make this process easier, the Electron team maintains the [`update-electron-app`] module,
|
||||
To make this process easier, the Electron team maintains the [`update-electron-app`][] module,
|
||||
which sets up the autoUpdater boilerplate for update.electronjs.org in one function
|
||||
call — no configuration required. This module will search for the update.electronjs.org
|
||||
feed that matches your project's package.json `"repository"` field.
|
||||
|
|
@ -214,7 +214,7 @@ own update server and configure the autoUpdater module yourself.
|
|||
|
||||
From here, you have officially completed our tutorial to Electron. Feel free to explore the
|
||||
rest of our docs and happy developing! If you have questions, please stop by our community
|
||||
[Discord server].
|
||||
[Discord server][].
|
||||
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Electron's [autoUpdater](../api/auto-updater.md) module.
|
|||
|
||||
## Using update.electronjs.org
|
||||
|
||||
The Electron team maintains [update.electronjs.org], a free and open-source
|
||||
The Electron team maintains [update.electronjs.org][], a free and open-source
|
||||
webservice that Electron apps can use to self-update. The service is designed
|
||||
for Electron apps that meet the following criteria:
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ for Electron apps that meet the following criteria:
|
|||
- Builds are published to [GitHub Releases][gh-releases]
|
||||
- Builds are [code-signed](./code-signing.md)
|
||||
|
||||
The easiest way to use this service is by installing [update-electron-app],
|
||||
The easiest way to use this service is by installing [update-electron-app][],
|
||||
a Node.js module preconfigured for use with update.electronjs.org.
|
||||
|
||||
Install the module using your Node.js package manager of choice:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ macOS, Windows, and Linux.
|
|||
|
||||
## Create frameless windows
|
||||
|
||||
A frameless window is a window that has no [chrome]. Not to be confused with the Google
|
||||
A frameless window is a window that has no [chrome][]. Not to be confused with the Google
|
||||
Chrome browser, window _chrome_ refers to the parts of the window (e.g. toolbars, controls)
|
||||
that are not a part of the web page.
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ win.setWindowButtonVisibility(false)
|
|||
|
||||
## Window Controls Overlay _macOS_ _Windows_
|
||||
|
||||
The [Window Controls Overlay API] is a web standard that gives web apps the ability to
|
||||
The [Window Controls Overlay API][] is a web standard that gives web apps the ability to
|
||||
customize their title bar region when installed on desktop. Electron exposes this API
|
||||
through the `BrowserWindow` constructor option `titleBarOverlay`.
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ const win = new BrowserWindow({ transparent: true })
|
|||
[#1335](https://github.com/electron/electron/issues/1335) for details.
|
||||
* Transparent windows are not resizable. Setting `resizable` to `true` may make
|
||||
a transparent window stop working on some platforms.
|
||||
* The CSS [`blur()`] filter only applies to the window's web contents, so there is no way to apply
|
||||
* The CSS [`blur()`][] filter only applies to the window's web contents, so there is no way to apply
|
||||
blur effect to the content below the window (i.e. other applications open on
|
||||
the user's system).
|
||||
* The window will not be transparent when DevTools is opened.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue