build: pre-build script
The pre-build scripts does the following: 1. Downloads the documentation from electron/electron and data/blog from electron/electronjs.org 2. Moves the files to the right folders based on the contents of `docs-reorg.json` 3. Add frontmatter to each file 4. Fixes internal links and multiline image titles 5. Generates the sidebar using the folder structure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Fix #6 Ref: Solves parts of #2
This commit is contained in:
Antón Molleda
Antón Molleda
Родитель
03b66ad977
Коммит
972a54e1d7
|
|
@ -1,3 +1,8 @@
|
|||
node_modules
|
||||
.docusaurus
|
||||
.DS_Store
|
||||
content/
|
||||
docs/
|
||||
blog/
|
||||
package-lock.json
|
||||
sidebars.js
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
{
|
||||
"singleQuote": true
|
||||
}
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
{
|
||||
// Use IntelliSense to learn about possible attributes.
|
||||
// Hover to view descriptions of existing attributes.
|
||||
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
|
||||
"version": "0.2.0",
|
||||
"configurations": [
|
||||
{
|
||||
"type": "pwa-node",
|
||||
"request": "launch",
|
||||
"name": "Launch Program",
|
||||
"skipFiles": ["<node_internals>/**"],
|
||||
"program": "${workspaceFolder}/scripts/pre-build.js",
|
||||
"console": "integratedTerminal",
|
||||
"cwd": "${workspaceFolder}"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
---
|
||||
title: New Electron Release Cadence
|
||||
author: sofianguy
|
||||
date: '2019-05-13'
|
||||
---
|
||||
|
||||
🎉 Electron is moving to release a new major stable version every 12 weeks! 🎉
|
||||
|
||||
---
|
||||
|
||||
## ⚡️ Wow that's quick! But why?
|
||||
|
||||
Simply put, Chromium doesn't stop shipping so Electron is not going to slow down either.
|
||||
|
||||
Chromium releases on a consistent 6-week [schedule](https://www.chromium.org/developers/calendar). To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found [here](https://chromium.googlesource.com/chromium/src/+/master/docs/process/release_cycle.md).
|
||||
|
||||
## 🚀 Why every 12 weeks?
|
||||
|
||||
Every 6 weeks, a new Chromium release comes out with new features, bug fixes / security fixes, and V8 improvements. Electron's users have been loud and clear about wanting these changes in a timely manner, so we've adjusted our stable release dates to match every other Chromium stable release. Up first, Electron v6.0.0 will include M76 and is scheduled for stable release on [July 30, 2019](https://electronjs.org/docs/tutorial/electron-timelines#600-release-schedule), the same release day as [Chromium M76](https://www.chromestatus.com/features/schedule).
|
||||
|
||||
## 🚧 What does this mean for me and my Electron app?
|
||||
|
||||
You'll have access to new Chromium and V8 features and fixes sooner than before. Importantly, you'll also know _when_ those new changes are coming, so you'll be able to plan with better information than before.
|
||||
|
||||
The Electron team will [continue to support](https://electronjs.org/docs/tutorial/support#supported-versions) the latest three major versions. For example, when [v6.0.0 goes stable on July 30, 2019](https://electronjs.org/docs/tutorial/electron-timelines#600-release-schedule), we will support v6.x, v5.x, and v4.x, while v3.x will reach End-Of-Life.
|
||||
|
||||
## 💬 App Feedback Program
|
||||
|
||||
Please consider joining our [App Feedback Program](https://electronjs.org/blog/app-feedback-program) to help us with testing our beta releases and stabilization. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release.
|
||||
|
||||
## 📝 A brief history of Electron releases
|
||||
|
||||
The decisions around stable releases before v3.0.0 did not follow a schedule. We added internal schedules to the project with v3.0.0 and v4.0.0. Earlier this year, we decided to publicize our stable release date for the first time for [Electron v5.0.0](https://electronjs.org/blog/electron-5-0-timeline). Announcing our stable release dates was positively received overall and we're excited to continue doing that for future releases.
|
||||
|
||||
In order to better streamline these upgrade-related efforts, our [Upgrades](https://github.com/electron/governance/tree/master/wg-upgrades) and [Releases](https://github.com/electron/governance/tree/master/wg-releases) Working Groups were created within our [Governance](https://electronjs.org/blog/governance) system. They have allowed us to better prioritize and delegate this work, which we hope will become more apparent with each subsequent release.
|
||||
|
||||
Here is where our new cadence will put us in comparison to Chromium's cadence:
|
||||
<img alt="line graph comparing Electron versus Chromium versions" src="https://user-images.githubusercontent.com/2138661/57543187-86340700-7308-11e9-9745-a9371bb29275.png"/>
|
||||
|
||||
📨 If you have questions, please mail us at [info@electronjs.org](mailto:info@electronjs.org).
|
||||
|
|
@ -1,97 +0,0 @@
|
|||
---
|
||||
title: What's New in Electron
|
||||
author: jlord
|
||||
date: '2015-10-15'
|
||||
---
|
||||
|
||||
There have been some interesting updates and talks given on Electron recently, here's a roundup.
|
||||
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
Electron is now up to date with Chrome 45 as of `v0.32.0`. Other updates include...
|
||||
|
||||
### Better Documentation
|
||||
|
||||
|
||||
|
||||
We have restructured and standardized the documentation to look better and read better. There are also community-contributed translations of the documentation, like Japanese and Korean.
|
||||
|
||||
Related pull requests:
|
||||
[electron/electron#2028](https://github.com/electron/electron/pull/2028),
|
||||
[electron/electron#2533](https://github.com/electron/electron/pull/2533),
|
||||
[electron/electron#2557](https://github.com/electron/electron/pull/2557),
|
||||
[electron/electron#2709](https://github.com/electron/electron/pull/2709),
|
||||
[electron/electron#2725](https://github.com/electron/electron/pull/2725),
|
||||
[electron/electron#2698](https://github.com/electron/electron/pull/2698),
|
||||
[electron/electron#2649](https://github.com/electron/electron/pull/2649).
|
||||
|
||||
### Node.js 4.1.0
|
||||
|
||||
Since `v0.33.0` Electron ships with Node.js 4.1.0.
|
||||
|
||||
Related pull request:
|
||||
[electron/electron#2817](https://github.com/electron/electron/pull/2817).
|
||||
|
||||
### node-pre-gyp
|
||||
|
||||
Modules relying on `node-pre-gyp` can now be compiled against Electron when building from source.
|
||||
|
||||
Related pull request:
|
||||
[mapbox/node-pre-gyp#175](https://github.com/mapbox/node-pre-gyp/pull/175).
|
||||
|
||||
### ARM Support
|
||||
|
||||
Electron now provides builds for Linux on ARMv7. It runs on popular platforms like Chromebook and Raspberry Pi 2.
|
||||
|
||||
Related issues:
|
||||
[atom/libchromiumcontent#138](https://github.com/atom/libchromiumcontent/pull/138),
|
||||
[electron/electron#2094](https://github.com/electron/electron/pull/2094),
|
||||
[electron/electron#366](https://github.com/electron/electron/issues/366).
|
||||
|
||||
### Yosemite-style Frameless Window
|
||||
|
||||
|
||||
|
||||
A patch by [@jaanus](https://github.com/jaanus) has been merged that, like the other built-in OS X apps, allows creating frameless windows with system traffic lights integrated on OS X Yosemite and later.
|
||||
|
||||
Related pull request:
|
||||
[electron/electron#2776](https://github.com/electron/electron/pull/2776).
|
||||
|
||||
### Google Summer of Code Printing Support
|
||||
|
||||
After the Google Summer of Code we have merged patches by [@hokein](https://github.com/hokein) to improve printing support, and add the ability to print the page into PDF files.
|
||||
|
||||
Related issues:
|
||||
[electron/electron#2677](https://github.com/electron/electron/pull/2677),
|
||||
[electron/electron#1935](https://github.com/electron/electron/pull/1935),
|
||||
[electron/electron#1532](https://github.com/electron/electron/pull/1532),
|
||||
[electron/electron#805](https://github.com/electron/electron/issues/805),
|
||||
[electron/electron#1669](https://github.com/electron/electron/pull/1669),
|
||||
[electron/electron#1835](https://github.com/electron/electron/pull/1835).
|
||||
|
||||
## Atom
|
||||
|
||||
Atom has now upgraded to Electron `v0.30.6` running Chrome 44. An upgrade to `v0.33.0` is in progress on [atom/atom#8779](https://github.com/atom/atom/pull/8779).
|
||||
|
||||
## Talks
|
||||
|
||||
GitHubber [Amy Palamountain](https://github.com/ammeep) gave a great introduction to Electron in a talk at [Nordic.js](https://nordicjs2015.confetti.events). She also created the [electron-accelerator](https://github.com/ammeep/electron-accelerator) library.
|
||||
|
||||
#### Building native applications with Electron by Amy Palomountain
|
||||
<div class="video"><iframe width="560" height="315" src="https://www.youtube.com/embed/OHOPSvTltPI" frameborder="0" allowfullscreen></iframe></div>
|
||||
|
||||
[Ben Ogle](https://github.com/benogle), also on the Atom team, gave an Electron talk at [YAPC Asia](http://yapcasia.org/2015/):
|
||||
|
||||
#### Building Desktop Apps with Web Technologies by Ben Ogle
|
||||
<div class="video"><iframe width="560" height="315" src="https://www.youtube.com/embed/WChjh5zaUdw" frameborder="0" allowfullscreen></iframe></div>
|
||||
|
||||
Atom team member [Kevin Sawicki](https://github.com/kevinsawicki) and others gave talks on Electron at the [Bay Are Electron User Group](http://www.meetup.com/Bay-Area-Electron-User-Group/) meetup recently. The [videos](http://www.wagonhq.com/blog/electron-meetup) have been posted, here are a couple:
|
||||
|
||||
#### The History of Electron by Kevin Sawicki
|
||||
<div class="video"><iframe width="560" height="315" src="https://www.youtube.com/embed/tP8Yp1boQ9c" frameborder="0" allowfullscreen></iframe></div>
|
||||
|
||||
#### Making a web app feel native by Ben Gotow
|
||||
<div class="video"><iframe width="560" height="315" src="https://www.youtube.com/embed/JIRXVGVPzn8" frameborder="0" allowfullscreen></iframe></div>
|
||||
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
title: Google Season of Docs
|
||||
author:
|
||||
- erickzhao
|
||||
date: '2020-05-21'
|
||||
---
|
||||
|
||||
Electron is proud to be participating in the second edition of Google's Season of Docs initiative, which pairs mentors from open source organizations with technical writers to improve project documentation.
|
||||
|
||||
---
|
||||
|
||||
# What is Season of Docs?
|
||||
|
||||
|
||||
|
||||
Season of Docs is a program that fosters collaboration between technical writers and open source communities to the benefit of both parties. Open source maintainers utilize the writer's technical writing expertise to improve the structure and content of their documentation, while the technical writer is introduced to an open-source community under the guidance of its mentors. Learn more about it on the Google's [Season of Docs website](https://developers.google.com/season-of-docs).
|
||||
|
||||
For our first time participating in the program, we'll be mentoring a single technical writer who will be working alongside Electron's [Ecosystem Working Group](https://github.com/electron/governance/tree/master/wg-ecosystem) to reshape large parts of our documentation. You can learn more about the timeline of the whole project [here](https://developers.google.com/season-of-docs/docs/timeline).
|
||||
|
||||
# How do I sign up?
|
||||
|
||||
Are you interested in collaborating with us as a technical writer? First, get familiar with Google's [tech writer guide](https://developers.google.com/season-of-docs/docs/tech-writer-guide) for this year's program, and check out the two [project idea drafts](https://github.com/electron/season-of-docs-2020/blob/master/project-ideas.md) that we have prepared.
|
||||
|
||||
In order to be selected as Electron's technical writer for Season of Docs, candidates will need to apply on the Google Season of Docs website during the Technical Writer Application phase that is running from June 8 to July 9..
|
||||
|
||||
Your application should include a proposal, which is a written document that describes in detail what you plan to achieve on the Electron docs over the course of 3 months. This proposal can either develop on one of the starting points mentioned in our Project Idea doc, or can be something entirely new. Don't know where to start? You can check out last year's [list of accepted proposals](https://developers.google.com/season-of-docs/docs/2019/participants) for inspiration.
|
||||
|
||||
Aside from the proposal, we'll also be looking at your background as a technical writer. Please include a copy of your resume with an emphasis on relevant writing experience, as well as technical writing samples (these samples could be existing documentation, tutorial, blog posts, etc.)
|
||||
|
||||
If you want to discuss project proposals, shoot us an email at [season-of-docs@electronjs.org](mailto:season-of-docs@electronjs.org) and we can chat from there!
|
||||
|
||||
# References
|
||||
* [Electron documentation](electronjs.org/docs)
|
||||
* [Project ideas document](https://github.com/electron/season-of-docs-2020/blob/master/project-ideas.md)
|
||||
* [Season of Docs tech writer guide](https://developers.google.com/season-of-docs/docs/tech-writer-guide)
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
---
|
||||
title: Accessibility Tools
|
||||
author: jlord
|
||||
date: '2016-08-23'
|
||||
---
|
||||
|
||||
Making accessible applications is important and we're happy to introduce new functionality to [Devtron](https://electronjs.org/devtron) and [Spectron](https://electronjs.org/spectron) that gives developers the opportunity to make their apps better for everyone.
|
||||
|
||||
---
|
||||
|
||||
Accessibility concerns in Electron applications are similar to those of websites because they're both ultimately HTML. With Electron apps, however, you can't use the online resources for accessibility audits because your app doesn't have a URL to point the auditor to.
|
||||
|
||||
These new features bring those auditing tools to your Electron app. You can choose to add audits to your tests with Spectron or use them within DevTools with Devtron. Read on for a summary of the tools or checkout our [accessibility documentation](https://electronjs.org/docs/tutorial/accessibility/) for more information.
|
||||
|
||||
### Spectron
|
||||
|
||||
In the testing framework Spectron, you can now audit each window and `<webview>` tag in your application. For example:
|
||||
|
||||
```javascript
|
||||
app.client.auditAccessibility().then(function (audit) {
|
||||
if (audit.failed) {
|
||||
console.error(audit.message)
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
You can read more about this feature in [Spectron's documentation](https://github.com/electron/spectron#accessibility-testing).
|
||||
|
||||
### Devtron
|
||||
|
||||
In Devtron there is a new accessibility tab which will allow you to audit a page in your app, sort and filter the results.
|
||||
|
||||
|
||||
|
||||
Both of these tools are using the [Accessibility Developer Tools](https://github.com/GoogleChrome/accessibility-developer-tools) library built by Google for Chrome. You can learn more about the accessibility audit rules this library uses on that [repository's wiki](https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules).
|
||||
|
||||
If you know of other great accessibility tools for Electron, add them to the [accessibility documentation](https://electronjs.org/docs/tutorial/accessibility/) with a pull request.
|
||||
|
||||
|
|
@ -1,124 +0,0 @@
|
|||
---
|
||||
title: Electron's API Docs as Structured Data
|
||||
author: zeke
|
||||
date: '2016-09-27'
|
||||
---
|
||||
|
||||
Today we're announcing some improvements to Electron's documentation. Every new
|
||||
release now includes a
|
||||
[JSON file](https://github.com/electron/electron/releases/download/v1.4.1/electron-api.json)
|
||||
that describes all of Electron's public APIs in detail. We created this file to
|
||||
enable developers to use Electron's API documentation in interesting new ways.
|
||||
|
||||
---
|
||||
|
||||
## Schema overview
|
||||
|
||||
Each API is an object with properties like name, description, type, etc.
|
||||
Classes such as `BrowserWindow` and `Menu` have additional properties describing
|
||||
their instance methods, instance properties, instance events, etc.
|
||||
|
||||
Here's an excerpt from the schema that describes the `BrowserWindow` class:
|
||||
|
||||
```js
|
||||
{
|
||||
name: 'BrowserWindow',
|
||||
description: 'Create and control browser windows.',
|
||||
process: {
|
||||
main: true,
|
||||
renderer: false
|
||||
},
|
||||
type: 'Class',
|
||||
instanceName: 'win',
|
||||
slug: 'browser-window',
|
||||
websiteUrl: 'https://electronjs.org/docs/api/browser-window',
|
||||
repoUrl: 'https://github.com/electron/electron/blob/v1.4.0/docs/api/browser-window.md',
|
||||
staticMethods: [...],
|
||||
instanceMethods: [...],
|
||||
instanceProperties: [...],
|
||||
instanceEvents: [...]
|
||||
}
|
||||
```
|
||||
|
||||
And here's an example of a method description, in this case the
|
||||
`apis.BrowserWindow.instanceMethods.setMaximumSize` instance method:
|
||||
|
||||
```js
|
||||
{
|
||||
name: 'setMaximumSize',
|
||||
signature: '(width, height)',
|
||||
description: 'Sets the maximum size of window to width and height.',
|
||||
parameters: [{
|
||||
name: 'width',
|
||||
type: 'Integer'
|
||||
}, {
|
||||
name: 'height',
|
||||
type: 'Integer'
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
## Using the new data
|
||||
|
||||
To make it easy for developers to use this structured data in their projects,
|
||||
we've created [electron-docs-api](https://www.npmjs.com/package/electron-api-docs), a small
|
||||
npm package that is published automatically whenever there's a new Electron
|
||||
release.
|
||||
|
||||
```sh
|
||||
npm install electron-api-docs --save
|
||||
```
|
||||
|
||||
For instant gratification, try out the module in your Node.js REPL:
|
||||
|
||||
```sh
|
||||
npm i -g trymodule && trymodule electron-api-docs=apis
|
||||
```
|
||||
|
||||
## How the data is collected
|
||||
|
||||
Electron's API documentation adheres to
|
||||
[Electron Coding Style](https://github.com/electron/electron/blob/master/docs/development/coding-style.md)
|
||||
and the
|
||||
[Electron Styleguide](https://github.com/electron/electron/blob/master/docs/styleguide.md#readme),
|
||||
so its content can be programmatically parsed.
|
||||
|
||||
The [electron-docs-linter](https://github.com/electron/electron-docs-linter)
|
||||
is a new development dependency of the `electron/electron` repository.
|
||||
It is a command-line tool that lints all the markdown files and enforces the
|
||||
rules of the styleguide. If errors are found, they are listed and the release
|
||||
process is halted. If the API docs are valid, the `electron-json.api` file
|
||||
is created and
|
||||
[uploaded to GitHub](https://github.com/electron/electron/releases/tag/v1.4.1)
|
||||
as part of the Electron release.
|
||||
|
||||
## Standard Javascript and Standard Markdown
|
||||
|
||||
Earlier this year, Electron's codebase was updated to use the
|
||||
[`standard`](http://standardjs.com/) linter for all JavaScript. Standard's
|
||||
README sums up the reasoning behind this choice:
|
||||
|
||||
> Adopting standard style means ranking the importance of code clarity and community conventions higher than personal style. This might not make sense for 100% of projects and development cultures, however open source can be a hostile place for newbies. Setting up clear, automated contributor expectations makes a project healthier.
|
||||
|
||||
We also recently created
|
||||
[standard-markdown](https://github.com/zeke/standard-markdown) to verify that
|
||||
all the JavaScript code snippets in our documentation are valid and consistent
|
||||
with the style in the codebase itself.
|
||||
|
||||
Together these tools help us use continuous integration (CI) to automatically
|
||||
find errors in pull requests. This reduces the burden placed on humans doing code
|
||||
review, and gives us more confidence about the accuracy of our documentation.
|
||||
|
||||
### A community effort
|
||||
|
||||
Electron's documentation is constantly improving, and we have our awesome
|
||||
open-source community to thank for it. As of this writing, nearly 300 people
|
||||
have contributed to the docs.
|
||||
|
||||
We're excited to see what people do with this new structured data. Possible uses
|
||||
include:
|
||||
|
||||
- Improvements to [https://electronjs.org/docs/](https://electronjs.org/docs/)
|
||||
- A [TypeScript definition file](https://github.com/electron/electron-docs-linter/blob/master/README.md#typescript-definitions) for more streamlined Electron development in projects using TypeScript.
|
||||
- Searchable offline documentation for tools like [Dash.app](https://kapeli.com/dash) and [devdocs.io](http://devdocs.io/)
|
||||
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
---
|
||||
title: Electron App Feedback Program
|
||||
author: sofianguy
|
||||
date: '2018-10-02'
|
||||
---
|
||||
|
||||
Electron is working on making its release cycles faster and more stable. To make that possible, we've started the App Feedback Program for large-scale Electron apps to test our beta releases and report app-specific issues to us. This helps us to prioritize work that will get applications upgraded to our next stable release sooner.
|
||||
|
||||
Edit (2020-05-21): This program has been retired.
|
||||
|
||||
---
|
||||
|
||||
## Who can join?
|
||||
Our criteria and expectations for apps joining this program include the following items:
|
||||
- Test your app during the beta period for 10,000+ user-hours
|
||||
- Have a single point-person who will check in weekly to discuss your app's Electron bugs and app blockers
|
||||
- You agree to abide by Electron's [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md)
|
||||
- You are willing to share the following information listed in the next question
|
||||
|
||||
## What info does my Electron app have to share?
|
||||
- Total user-hours your app has been running with any beta release
|
||||
- Version of Electron that your app is testing with (e.g., 4.0.0-beta.3)
|
||||
- Any bugs preventing your application from upgrading to the release line being beta tested
|
||||
|
||||
## User-hours
|
||||
We understand not everyone can share exact user numbers, however better data helps us decide how stable a particular release is. We ask that apps commit to testing a minimum number of user-hours, currently 10,000 across the beta cycle.
|
||||
- 10 user-hours could be 10 people testing for one hour, or one person testing for 10 hours
|
||||
- You can split the testing between beta releases, for example test for 5,000 user-hours on 3.0.0-beta.2 and then test for 5,000 user-hours on 3.0.0-beta.5. More is better, but we understand that some applications cannot test every beta release
|
||||
- CI or QA hours do not count towards the total; however, internal releases do count
|
||||
|
||||
## Why should my Electron app join?
|
||||
Your app's bugs will be tracked and be on the core Electron team's radar. Your feedback helps the Electron team to see how the new betas are doing and what work needs to be done.
|
||||
|
||||
## Will my application's info be shared publicly? Who gets to see this info?
|
||||
No, your application's information will not be shared with the general public. Information is kept in a private GitHub repo that is only viewable to members of the App Feedback Program and [Electron Governance](https://github.com/electron/governance). All members have agreed to follow Electron's [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md).
|
||||
|
||||
## Sign up
|
||||
We are currently accepting a *limited number* of signups. If you are interested and are able to fulfill the above requirements, please fill out this [form](https://goo.gl/forms/OpMEKV75ScN6we7g1).
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
---
|
||||
title: Apple Silicon Support
|
||||
author: MarshallOfSound
|
||||
date: '2020-10-15'
|
||||
---
|
||||
|
||||
With Apple Silicon hardware being released later this year, what does the path look like for you to get your Electron app running on the new hardware?
|
||||
|
||||
---
|
||||
|
||||
With the release of Electron 11.0.0-beta.1, the Electron team is now shipping builds of Electron that run on the new Apple Silicon hardware that Apple plans on shipping later this year. You can grab the latest beta with `npm install electron@beta` or download it directly from our [releases website](https://electronjs.org/releases/stable).
|
||||
|
||||
## How does it work?
|
||||
|
||||
As of Electron 11, we will be shipping separate versions of Electron for Intel Macs and Apple Silicon Macs. Prior to this change, we were already shipping two artifacts, `darwin-x64` and `mas-x64`, with the latter being for Mac App Store compatibility usage. We are now shipping another two artifacts, `darwin-arm64` and `mas-arm64`, which are the Apple Silicon equivalents of the aforementioned artifacts.
|
||||
|
||||
## What do I need to do?
|
||||
|
||||
You will need to ship two versions of your app: one for x64 (Intel Mac) and one for arm64 (Apple Silicon). The good news is that [`electron-packager`](https://github.com/electron/electron-packager/), [`electron-rebuild`](https://github.com/electron/electron-rebuild/) and [`electron-forge`](https://github.com/electron-userland/electron-forge/) already support targeting the `arm64` architecture. As long as you're running the latest versions of those packages, your app should work flawlessly once you update the target architecture to `arm64`.
|
||||
|
||||
In the future, we will release a package that allows you to "merge" your `arm64` and `x64` apps into a single universal binary, but it's worth noting that this binary would be _huge_ and probably isn't ideal for shipping to users.
|
||||
|
||||
## Potential Issues
|
||||
|
||||
### Native Modules
|
||||
|
||||
As you are targeting a new architecture, you'll need to update several dependencies which may cause build issues. The minimum version of certain dependencies are included below for your reference.
|
||||
|
||||
| Dependency | Version Requirement |
|
||||
|------------|---------------------|
|
||||
| Xcode | `>=12.2.0` |
|
||||
| `node-gyp` | `>=7.1.0` |
|
||||
| `electron-rebuild` | `>=1.12.0` |
|
||||
| `electron-packager` | `>=15.1.0` |
|
||||
|
||||
As a result of these dependency version requirements, you may have to fix/update certain native modules. One thing of note is that the Xcode upgrade will introduce a new version of the macOS SDK, which may cause build failures for your native modules.
|
||||
|
||||
|
||||
## How do I test it?
|
||||
|
||||
Currently, Apple Silicon applications only run on Apple Silicon hardware, which isn't commercially available at the time of writing this blog post. If you have a [Developer Transition Kit](https://developer.apple.com/programs/universal/), you can test your application on that. Otherwise, you'll have to wait for the release of production Apple Silicon hardware to test if your application works.
|
||||
|
||||
## What about Rosetta 2?
|
||||
|
||||
Rosetta 2 is Apple's latest iteration of their [Rosetta](https://en.wikipedia.org/wiki/Rosetta_(software)) technology, which allows you to run x64 Intel applications on their new arm64 Apple Silicon hardware. Although we believe that x64 Electron apps will run under Rosetta 2, there are some important things to note (and reasons why you should ship a native arm64 binary).
|
||||
|
||||
* Your app's performance will be significantly degraded. Electron / V8 uses [JIT](https://en.wikipedia.org/wiki/Just-in-time_compilation) compilation for JavaScript, and due to how Rosetta works, you will effectively be running JIT twice (once in V8 and once in Rosetta).
|
||||
* You lose the benefit of new technology in Apple Silicon, such as the increased memory page size.
|
||||
* Did we mention that the performance will be **significantly** degraded?
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
title: 'August 2016: New Apps'
|
||||
author: jlord
|
||||
date: '2016-09-06'
|
||||
---
|
||||
|
||||
Here are the new Electron apps that were added to the site in August.
|
||||
|
||||
---
|
||||
|
||||
The site is updated with new [apps](https://electronjs.org/apps) and [meetups](https://electronjs.org/community) through [pull requests](https://github.com/electron/electronjs.org/pulls) from the community. You can [watch the repository](https://github.com/electron/electronjs.org) to get notifications of new additions or if you're not interested in _all_ of the site's changes, subscribe to the [blog RSS feed](https://electronjs.org/feed.xml).
|
||||
|
||||
If you've made an Electron app or host a meetup, make a [pull request](https://github.com/electron/electronjs.org) to add it to the site and it will make the next roundup.
|
||||
|
||||
### New Apps
|
||||
|
||||
{: .table .table-ruled .table-full-width .table-with-spacious-first-column .mb-7}
|
||||
|
||||
| | | |
|
||||
| --- | --- | -- |
|
||||
| <img src='/images/apps/coderpgify.png' width='50'/> | [Code RPGify](http://code.rpgify.com) | RPG style coding application |
|
||||
| <img src='/images/apps/pamfax.png' width='50'/> | [PamFax](https://www.pamfax.biz) | A cross-platform app for sending and receiving faxes |
|
||||
| <img src='/images/apps/blankup.png' width='50'/> | [BlankUp](https://hoverbaum.github.io/BlankUp-Electron/) | Markdown editor witch clarity +1 |
|
||||
| <img src='/images/apps/rambox.png' width='50'/> | [Rambox](http://rambox.pro) | Free and Open Source messaging and emailing app that combines common web applications into one |
|
||||
| <img src='/images/apps/gordie.png' width='50'/> | [Gordie](http://gordie-app.bitbucket.org/) | The best app for your card collections |
|
||||
| <img src='/images/apps/ionic-creator.png' width='50'/> | [Ionic Creator](https://github.com/Meadowcottage/Ionic-Creator) | Build amazing mobile apps, faster |
|
||||
| <img src='/images/apps/twitchalerts.png' width='50'/> | [TwitchAlerts](https://github.com/Meadowcottage/TwitchAlerts) | Keep your viewers happy with beautiful alerts and notifications |
|
||||
| <img src='/images/apps/museeks.png' width='50'/> | [Museeks](http://museeks.io/) | A simple, clean and cross-platform music player |
|
||||
| <img src='/images/apps/seapig.png' width='50'/> | [SeaPig](https://github.com/yasumichi/seapig/blob/master/README.md) | A converter from markdown to html |
|
||||
| <img src='/images/apps/groupme.png' width='50'/> | [GroupMe](https://github.com/dcrousso/GroupMe#readme) | Unofficial GroupMe App |
|
||||
| <img src='/images/apps/moeditor.png' width='50'/> | [Moeditor](https://moeditor.github.io/) | Your all-purpose markdown editor |
|
||||
| <img src='/images/apps/soundnode.png' width='50'/> | [Soundnode](http://www.soundnodeapp.com) | Soundnode App is the Soundcloud for desktop |
|
||||
| <img src='/images/apps/qmui.png' width='50'/> | [QMUI Web](http://qmuiteam.com/web) | QMUI Web Desktop is an application for managing projects based on QMUI Web Framework |
|
||||
| <img src='/images/apps/svgsus.png' width='50'/> | [Svgsus](http://www.svgs.us) | Organize, clean and transform your SVGs |
|
||||
| <img src='/images/apps/ramme.png' width='50'/> | [Ramme](https://github.com/terkelg/ramme) | Unofficial Instagram Desktop App |
|
||||
| <img src='/images/apps/insomnia.png' width='50'/> | [Insomnia](https://insomnia.rest/) | REST API Client |
|
||||
| <img src='/images/apps/correo.png' width='50'/> | [Correo](https://github.com/amitmerchant1990/correo) | A menubar/taskbar Gmail App for Windows, macOS and Linux |
|
||||
| <img src='/images/apps/kongdash.png' width='50'/> | [KongDash](https://ajaysreedhar.github.io/kongdash) | Desktop client for Kong Admin API |
|
||||
| <img src='/images/apps/react-intl-translation-editor.png' width='50'/> | [Translation Editor](https://bitbucket.org/bflower/react-intl-editor/wiki/Home) | Translation files editor for INTL ICU messages (see formatjsio) |
|
||||
| <img src='/images/apps/5eplay.png' width='50'/> | [5EClient](https://www.5eplay.com/) | 5EPlay CSGO Client |
|
||||
| <img src='/images/apps/theme-juice.png' width='50'/> | [Theme Juice](https://www.themejuice.it) | Local WordPress development made easy |
|
||||
|
|
@ -1,98 +0,0 @@
|
|||
---
|
||||
title: Easier AutoUpdating for Open-Source Apps
|
||||
author: zeke
|
||||
date: '2018-05-01'
|
||||
---
|
||||
|
||||
Today we're releasing a free, open-source, hosted
|
||||
[updates webservice][update.electronjs.org] and companion
|
||||
[npm package][update-electron-app]
|
||||
to enable easy automatic updates for open-source Electron apps. This is a step
|
||||
toward empowering app developers to think less about
|
||||
deployment and more about developing high-quality experiences for their users.
|
||||
|
||||
---
|
||||
|
||||
<figure>
|
||||
<a href="https://github.com/electron/update-electron-app" style="display: block; text-align: center;">
|
||||
<img class="screenshot" src="https://user-images.githubusercontent.com/2289/39480716-e9990910-4d1d-11e8-8901-9549c6ff6050.png" alt="Updater Screenshot"/>
|
||||
<figcaption>The new updater module in action</figcaption>
|
||||
</a>
|
||||
</figure>
|
||||
|
||||
## Making life easier
|
||||
|
||||
Electron has an [autoUpdater] API that gives apps the ability to
|
||||
consume metadata from a remote endpoint to check for updates, download them
|
||||
in the background, and install them automatically.
|
||||
|
||||
Enabling these updates has been a cumbersome step in the deployment process
|
||||
for many Electron app developers because it requires a web server to be deployed
|
||||
and maintained just to serve app version history metadata.
|
||||
|
||||
Today we are announcing a new drop-in solution for automatic app updates.
|
||||
If your Electron app is in a public GitHub repository and you're using
|
||||
GitHub Releases to publish builds, you can use this service to deliver
|
||||
continuous app updates to your users.
|
||||
|
||||
## Using the new module
|
||||
|
||||
To minimize configuration on your part, we've created [update-electron-app],
|
||||
an npm module which integrates with the new [update.electronjs.org] webservice.
|
||||
|
||||
Install the module:
|
||||
|
||||
```sh
|
||||
npm install update-electron-app
|
||||
```
|
||||
|
||||
Call it from anywhere in your app's [main process]:
|
||||
|
||||
```js
|
||||
require('update-electron-app')()
|
||||
```
|
||||
|
||||
That's it! The module will check for updates at app startup, then
|
||||
every ten minutes. When an update is found it will download automically
|
||||
in the background, and a dialog will be displayed when the update is ready.
|
||||
|
||||
## Migrating existing apps
|
||||
|
||||
Apps already using Electron's autoUpdater API can use this service too.
|
||||
To do so, you can
|
||||
[customize the `update-electron-app`][update-electron-app] module
|
||||
or
|
||||
[integrate directly with update.electronjs.org][update.electronjs.org].
|
||||
|
||||
## Alternatives
|
||||
|
||||
If you're using [electron-builder] to package your app, you can use its
|
||||
built-in updater. For details, see
|
||||
[electron.build/auto-update](https://www.electron.build/auto-update).
|
||||
|
||||
If your app is private, you may need to run your own update server. There are
|
||||
a number of open-source tools for this, including Zeit's [Hazel] and
|
||||
Atlassian's [Nucleus]. See the [Deploying an Update Server] tutorial for more
|
||||
info.
|
||||
|
||||
## Thanks
|
||||
|
||||
Thanks to [Julian Gruber] for helping design and build this simple and scalable
|
||||
web service. Thanks to the folks at [Zeit] for their open-source [Hazel]
|
||||
service, from which we drew design inspiration. Thanks to [Samuel Attard] for
|
||||
the code reviews. Thanks to the Electron community for helping test this
|
||||
service.
|
||||
|
||||
🌲 Here's to an evergreen future for Electron apps!
|
||||
|
||||
[autoUpdater]: https://electronjs.org/docs/tutorial/updates
|
||||
[electron-builder]: https://github.com/electron-userland/electron-builder
|
||||
[Hazel]: https://github.com/zeit/hazel
|
||||
[Julian Gruber]: http://juliangruber.com/
|
||||
[main process]: https://electronjs.org/docs/glossary#main-process
|
||||
[Deploying an Update Server]: https://electronjs.org/docs/tutorial/updates#deploying-an-update-server
|
||||
[Nucleus]: https://github.com/atlassian/nucleus
|
||||
[Samuel Attard]: https://www.samuelattard.com/
|
||||
[update-electron-app]: https://github.com/electron/update-electron-app
|
||||
[update.electronjs.org]: https://github.com/electron/update.electronjs.org
|
||||
[Zeit]: https://zeit.co
|
||||
|
|
@ -1,90 +0,0 @@
|
|||
---
|
||||
title: 'Project of the Week: Beaker Browser'
|
||||
author:
|
||||
- pfrazee
|
||||
- zeke
|
||||
date: '2017-02-07'
|
||||
---
|
||||
|
||||
This week we caught up with [Paul Frazee](http://pfrazee.github.io/), creator
|
||||
of [Beaker Browser](https://beakerbrowser.com/). Beaker is an experimental
|
||||
peer-to-peer web browser that uses the Dat protocol to host sites from users’
|
||||
devices.
|
||||
|
||||
---
|
||||
|
||||
<iframe width="100%" height="420" src="https://www.youtube.com/embed/Bem9nRpyPEs" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
## What is Beaker and why did you create it?
|
||||
|
||||
Beaker is a participatory browser. It's a browser for indie hackers.
|
||||
|
||||
The Web is closed source. If you want to influence how social media works, you have to work at Facebook or Twitter. For search, Google. Control is in the hands of companies, rather than the users themselves.
|
||||
|
||||
With Beaker, we have a new Web protocol: the [Decentralized Archive Transport](https://datprotocol.com). "Dat." It creates sites on demand, for free, and then shares them from the device. No servers required. That's our innovation.
|
||||
|
||||
|
||||
|
||||
When you visit a Dat site in Beaker, you download the files. The site is yours, forever. You can save it, fork it, modify it, and share your new version for free. It's all open-source.
|
||||
|
||||
So that's what it's about: We're making a browser for open-source Websites. We want it to be a toolkit for social hacking.
|
||||
|
||||
## Who should be using Beaker?
|
||||
|
||||
Hackers. Modders. Creative types. People who like to tinker.
|
||||
|
||||
## How do I create a new project that uses Dat?
|
||||
|
||||
We've got [a command-line tool called bkr](https://github.com/beakerbrowser/bkr) that's kind of like git + npm. Here's creating a site:
|
||||
|
||||
```bash
|
||||
$ cd ~/my-site
|
||||
$ bkr init
|
||||
$ echo "Hello, world!" > index.html
|
||||
$ bkr publish
|
||||
```
|
||||
|
||||
And here's forking a site:
|
||||
|
||||
```bash
|
||||
$ bkr fork dat://0ff7d4c7644d0aa19914247dc5dbf502d6a02ea89a5145e7b178d57db00504cd/ ~/my-fork
|
||||
$ cd ~/my-fork
|
||||
$ echo "My fork has no regard for the previous index.html!" > index.html
|
||||
$ bkr publish
|
||||
```
|
||||
|
||||
Those sites then get hosted out of your browser. It's a little like BitTorrent; you share the sites in a P2P mesh.
|
||||
|
||||
If you want a GUI, we have some basic tools built into the browser, but we're pushing those tools into userland. It's all going to be moddable user apps.
|
||||
|
||||
## Why did you choose to build Beaker on Electron?
|
||||
|
||||
It was obvious for this project. If I forked Chrome myself, I'd be writing C++ right now! Nobody wants to do that. I know the Web stack, and I can work quickly with it. It's a no-brainer.
|
||||
|
||||
The truth is, I'm not sure I could do any of this without Electron. It's a great piece of software.
|
||||
|
||||
## What are some challenges you've faced while building Beaker?
|
||||
|
||||
Half of it is poking at the tools and figuring out how much I can get away with.
|
||||
|
||||
Making the browser itself was pretty easy. Electron is practically a toolkit for making browsers. ...Except for the browser tabs; that took me forever to get right. I finally broke down and learned how to do SVGs. It's much better looking, but it took 3 or 4 iterations before I got that right.
|
||||
|
||||
## In what areas should Electron be improved?
|
||||
|
||||
It'd be really great if I could dock the devtools inside a webview.
|
||||
|
||||
## What's coming next in Beaker?
|
||||
|
||||
Secure DNS names for Dat sites. A socially configurable URL scheme, called the ["app scheme."](https://github.com/beakerbrowser/beaker/wiki/App-Scheme) More Dat APIs.
|
||||
|
||||
## For folks who may be interested in contributing to the project, in what areas does Beaker need help?
|
||||
|
||||
We have lots of open issues. Don't be afraid to ping me. #beakerbrowser on freenode. We keep a [page for contributors](https://beakerbrowser.com/docs/team.html) and we'll add you to it. And if you visit Austin, I'll buy you a beer.
|
||||
|
||||
## Any Electron tips that might be useful to other developers?
|
||||
|
||||
1. Use the build tooling that's out there. You don't want to wrestle with your own solutions, trust me. Use electron-builder. Use a boilerplate repo.
|
||||
2. If you need to open an issue in the Electron repo, go the extra mile to make it easy to reproduce. You'll get a response much more quickly, and the team will appreciate it. Even better, try fixing it yourself. It's actually pretty interesting to see the innards.
|
||||
3. Read through all the guides and advanced docs at least once.
|
||||
4. Don't build a browser, it's a saturated market.
|
||||
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
---
|
||||
title: Upcoming Electron Releases
|
||||
author: codebytere
|
||||
date: '2020-03-19'
|
||||
---
|
||||
|
||||
Electron is temporarily pausing major releases
|
||||
|
||||
---
|
||||
|
||||
## What's Happening?
|
||||
|
||||
Our [major release cadence schedule](https://www.electronjs.org/blog/12-week-cadence) moves in lockstep with that of Chromium, and the Chromium project has made the recent decision to [pause its releases](https://blog.chromium.org/2020/03/upcoming-chrome-releases.html) due to adjusted work schedules. This means that for the duration of Chromium's altered cadence, Electron will also temporarily pause new major releases.
|
||||
|
||||
We feel that our best choice is to follow in Chromium's footsteps, and so in the interim the Electron team will shift to full-time work on bugfixes, security, performance, and stability.
|
||||
|
||||
We want to ensure that both our maintainers and our consumers' wellbeing is prioritized during this time, so we welcome your feedback and look forward to returning to our regular release schedule.
|
||||
|
||||
For more updates, please follow our [Twitter account](https://twitter.com/electronjs).
|
||||
|
||||
Edit (2020-03-30): Electron 9 stable will target Chromium M83 and be released on May 19, 2020, in response to [Chromium's announcement](https://chromereleases.googleblog.com/2020/03/chrome-and-chrome-os-release-updates.html) of skipping the M82 stable date and adjusting the M83 stable date.
|
||||
|
|
@ -1,119 +0,0 @@
|
|||
---
|
||||
title: Certificate Transparency Fix
|
||||
author: kevinsawicki
|
||||
date: '2016-12-09'
|
||||
---
|
||||
|
||||
Electron [1.4.12] contains an important patch that fixes an upstream Chrome
|
||||
issue where some Symantec, GeoTrust, and Thawte SSL/TLS certificates
|
||||
are incorrectly rejected 10 weeks from the build time of [libchromiumcontent],
|
||||
Electron's underlying Chrome library. There are no issues with the certificates
|
||||
used on the affected sites and replacing these certificates will not help.
|
||||
|
||||
---
|
||||
|
||||
In Electron 1.4.0 — 1.4.11 HTTPS requests to sites using these affected
|
||||
certificates will fail with network errors after a certain date.
|
||||
This affects HTTPS requests made using Chrome's underlying networking APIs
|
||||
such as `window.fetch`, Ajax requests, Electron's `net` API,
|
||||
`BrowserWindow.loadURL`, `webContents.loadURL`, the `src` attribute on a
|
||||
`<webview>` tag, and others.
|
||||
|
||||
Upgrading your applications to 1.4.12 will prevent these request failures from
|
||||
occurring.
|
||||
|
||||
**Note:** This issue was introduced in Chrome 53 so Electron versions earlier
|
||||
than 1.4.0 are not affected.
|
||||
|
||||
### Impact Dates
|
||||
|
||||
Below is a table of each Electron 1.4 version and the date when
|
||||
requests to sites using these affected certificates will start to fail.
|
||||
|
||||
<table class="table table-ruled table-full-width">
|
||||
<thead>
|
||||
<tr class="text-left">
|
||||
<th>Electron Version</th>
|
||||
<th>Impact Date</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>1.3.x</td>
|
||||
<td>Unaffected</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.0</td>
|
||||
<td>Already failing</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.1</td>
|
||||
<td>Already failing</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.2</td>
|
||||
<td>Already failing</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.3</td>
|
||||
<td>December 10th, 2016 9:00 PM PST</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.4</td>
|
||||
<td>December 10th, 2016 9:00 PM PST</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.5</td>
|
||||
<td>December 10th, 2016 9:00 PM PST</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.6</td>
|
||||
<td>January 14th, 2017 9:00 PM PST</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.7</td>
|
||||
<td>January 14th, 2017 9:00 PM PST</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.8</td>
|
||||
<td>January 14th, 2017 9:00 PM PST</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.9</td>
|
||||
<td>January 14th, 2017 9:00 PM PST</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.10</td>
|
||||
<td>January 14th, 2017 9:00 PM PST</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.11</td>
|
||||
<td>February 11th, 2017 9:00 PM PST</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1.4.12</td>
|
||||
<td>Unaffected</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
You can verify your app's impact date by setting your computer's clock ahead
|
||||
and then check to see if [https://symbeta.symantec.com/welcome/](https://symbeta.symantec.com/welcome/)
|
||||
successfully loads from it.
|
||||
|
||||
## More Information
|
||||
|
||||
You can read more about this topic, the original issue, and the fix at the
|
||||
following places:
|
||||
|
||||
- [What is Certificate Transparency?](https://www.certificate-transparency.org/what-is-ct)
|
||||
- [Symtantec knowledge base article](https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&id=ALERT2160)
|
||||
- [Chrome issue 664177](https://bugs.chromium.org/p/chromium/issues/detail?id=664177)
|
||||
- [Chrome fix for issue 664177](https://codereview.chromium.org/2495583002)
|
||||
- [libchromiumcontent patch for issue 664177](https://github.com/electron/libchromiumcontent/pull/248)
|
||||
|
||||
[libchromiumcontent]: https://github.com/electron/libchromiumcontent
|
||||
[1.4.12]: https://github.com/electron/electron/releases/tag/v1.4.12
|
||||
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
title: Chromium RCE Vulnerability Fix
|
||||
author: zeke
|
||||
date: '2017-09-27'
|
||||
---
|
||||
|
||||
A remote code execution vulnerability has been discovered in Google Chromium
|
||||
that affects all recent versions of Electron. Any Electron app that accesses
|
||||
remote content is vulnerable to this exploit, regardless of whether the
|
||||
[sandbox option] is enabled.
|
||||
|
||||
We've published two new versions of electron `1.7.8` and `1.6.14`,
|
||||
both of which include a fix for this vulnerability. We urge all Electron
|
||||
developers to update their apps to the latest stable version immediately:
|
||||
|
||||
```sh
|
||||
npm i electron@latest --save-dev
|
||||
```
|
||||
|
||||
To learn more about best practices for keeping your Electron apps secure,
|
||||
see our [security tutorial].
|
||||
|
||||
Please contact security@electronjs.org if you wish to report a vulnerability in
|
||||
Electron.
|
||||
|
||||
[sandbox option]: https://electronjs.org/docs/api/sandbox-option
|
||||
[security tutorial]: https://electronjs.org/docs/tutorial/security
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
---
|
||||
title: Chromium WebAudio Vulnerability Fix (CVE-2019-13720)
|
||||
author: nornagon
|
||||
date: '2019-11-04'
|
||||
---
|
||||
|
||||
A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.
|
||||
|
||||
This vulnerability has been assigned `CVE-2019-13720`. You can read more about it in the [Chrome Blog Post][announcement].
|
||||
|
||||
Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron as soon as possible.
|
||||
|
||||
---
|
||||
|
||||
## Scope
|
||||
|
||||
This affects any Electron application that may run third-party or untrusted JavaScript.
|
||||
|
||||
## Mitigation
|
||||
|
||||
Affected apps should upgrade to a patched version of Electron.
|
||||
|
||||
We've published new versions of Electron which include fixes for this vulnerability:
|
||||
* [6.1.4](https://github.com/electron/electron/releases/tag/v6.1.4)
|
||||
|
||||
Electron 7.0.1 automatically included the fix from upstream, before the announcement was made. Electron 8 is similarly unaffected. The vulnerability did not exist in Electron 5, so that version is also unaffected.
|
||||
|
||||
## Further Information
|
||||
|
||||
This vulnerability was discovered by Anton Ivanov and Alexey Kulaev at Kaspersky Labs and reported to the Chrome team. The Chrome blog post can be found [here][announcement].
|
||||
|
||||
To learn more about best practices for keeping your Electron apps secure, see our [security tutorial].
|
||||
|
||||
If you wish to report a vulnerability in Electron, email security@electronjs.org.
|
||||
|
||||
[security tutorial]: https://electronjs.org/docs/tutorial/security
|
||||
[announcement]: https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop_31.html
|
||||
99
blog/dat.md
99
blog/dat.md
|
|
@ -1,99 +0,0 @@
|
|||
---
|
||||
title: 'Project of the Week: Dat'
|
||||
author:
|
||||
- karissa
|
||||
- yoshuawuyts
|
||||
- maxogden
|
||||
- zeke
|
||||
date: '2017-02-21'
|
||||
---
|
||||
|
||||
This week's featured project is [Dat](https://datproject.org/), a
|
||||
[grant-funded](https://changelog.com/rfc/6), open source, decentralized tool
|
||||
for distributing data sets. Dat is built and maintained by a
|
||||
[geodistributed team](https://datproject.org/team), many of whom helped
|
||||
write this post.
|
||||
|
||||
---
|
||||
|
||||
[](https://github.com/datproject/dat-desktop)
|
||||
|
||||
## First off what is Dat?
|
||||
|
||||
We wanted to bring the best parts of peer to peer and distributed systems to data sharing. We started with scientific data sharing and then began branching out into research institutions, government, public service, and open source teams as well.
|
||||
|
||||
Another way to think about it is a sync and upload app like Dropbox or BitTorrent Sync, except Dat is [open source](https://github.com/datproject). Our goal is to be a a powerful, open source, non-profit data sharing software for big, small, medium, small-batch and big-batch data.
|
||||
|
||||
To use the `dat` CLI tool, all you have to type is:
|
||||
|
||||
```sh
|
||||
dat share path/to/my/folder
|
||||
```
|
||||
|
||||
And dat will create a link that you can use to send that folder to someone else -- no central servers or third parties get access to your data. Unlike BitTorrent, it's also impossible to sniff who is sharing what ([see the Dat Paper draft for more details](https://github.com/datproject/docs/blob/master/papers/dat-paper.md)).
|
||||
|
||||
## Now we know what Dat is. How does Dat Desktop fit in?
|
||||
|
||||
[Dat Desktop](https://github.com/datproject/dat-desktop) is a way to make Dat accessible to people who can't or don't want to use the command line. You can host multiple dats on your machine and serve the data over your network.
|
||||
|
||||
## Can you share some cool use cases?
|
||||
|
||||
### DataRefuge + Project Svalbard
|
||||
|
||||
We're working on a thing codenamed [Project Svalbard](https://github.com/datproject/svalbard) that is related to [DataRefuge](http://www.ppehlab.org/datarefuge), a group working to back up government climate data at risk of disappearing. Svalbard is named after the Svalbard Global Seed Vault in the Arctic which has a big underground backup library of plant DNA. Our version of it is a big version controlled collection of public scientific datasets. Once we know and can trust the metadata, we can build other cool projects like a [distributed volunteer data storage network](https://github.com/datproject/datasilo/).
|
||||
|
||||
### California Civic Data Coalition
|
||||
|
||||
[CACivicData](http://www.californiacivicdata.org/) is an open-source archive serving up daily downloads from CAL-ACCESS, California's database tracking money in politics. They do [daily releases](http://calaccess.californiacivicdata.org/downloads/0), which means hosting a lot of duplicate data across their zip files. We're working on hosting their data as a Dat repository which will reduce the amount of hassle and bandwidth needed to refer to specific version or update to a newer version.
|
||||
|
||||
## Electron Updates
|
||||
|
||||
This one isn't concrete yet, but we think a fun use case would be putting a compiled Electron app in a Dat repository, then using a Dat client in Electron to pull the latest deltas of the built app binary, to save on download time but also to reduce bandwidth costs for the server.
|
||||
|
||||
## Who should be using Dat Desktop?
|
||||
|
||||
Anyone who wants to share and update data over a p2p network. Data scientists, open data hackers, researchers, developers. We're super receptive to feedback if anyone has a cool use case we haven't thought of yet. You can drop by our [Gitter Chat](https://gitter.im/datproject/discussions) and ask us anything!
|
||||
|
||||
## What's coming next in Dat and Dat Desktop?
|
||||
|
||||
User accounts and metadata publishing. We are working on a Dat registry web app to be deployed at [datproject.org](https://datproject.org/) which will basically be an 'NPM for datasets', except the caveat being we are just going to be a metadata directory and the data can live anywhere online (as opposed to NPM or GitHub where all the data is centrally hosted, because source code is small enough you can fit it all in one system). Since many datasets are huge, we need a federated registry (similar to how BitTorrent trackers work). We want to make it easy for people to find or publish datasets with the registry from Dat Desktop, to make the data sharing process frictionless.
|
||||
|
||||
Another feature is multi-writer/collaborative folders. We have big plans to do collaborative workflows, maybe with branches, similar to git, except designed around dataset collaboration. But we're still working on overall stability and standardizing our protocols right now!
|
||||
|
||||
## Why did you choose to build Dat Desktop on Electron?
|
||||
|
||||
Dat is built using Node.js, so it was a natural fit for our integration. Beyond this, our users use a variety of machines
|
||||
since scientists, researchers and government officials may be forced to use certain setups for their institutions -- this means we need to be able to target Windows and Linux as well as Mac. Dat Desktop gives us that quite easily.
|
||||
|
||||
## What are some challenges you've faced while building Dat and Dat Desktop?
|
||||
|
||||
Figuring out what people want. We started with tabular datasets, but we realized that it was a bit of a complicated problem to solve and that most people don't use databases. So half way through the project, we redesigned everything from scratch to use a filesystem and haven't looked back.
|
||||
|
||||
We also ran into some general Electron infrastructure problems, including:
|
||||
|
||||
- Telemetry - how to capture anonymous usage statistics
|
||||
- Updates - It's kind of piecemeal and magic to set up automatic updates
|
||||
- Releases - XCode signing, building releases on Travis, doing beta builds, all were challenges.
|
||||
|
||||
We also use Browserify and some cool Browserify Transforms on the 'front end' code in Dat Desktop (which is kind of weird because we still bundle even though we have native `require` -- but it's because we want the Transforms). To better help manage our CSS we switched from Sass to using [sheetify](https://github.com/stackcss/sheetify). It's greatly helped us modularize our CSS and made it easier to move our UI to a component oriented architecture with shared dependencies. For example [dat-colors](https://github.com/Kriesse/dat-colors) contains all of our colors and is shared between all our projects.
|
||||
|
||||
We've always been a big fan of standards and minimal abstractions. Our whole interface is built using regular DOM nodes with just a few helper libraries. We've started to move some of these components into [base-elements](https://base.choo.io), a library of low-level reusable components. As with most of our technology we keep iterating on it until we get it right, but as a team we have a feeling we're heading in the right direction here.
|
||||
|
||||
## In what areas should Electron be improved?
|
||||
|
||||
We think the biggest pain point is native modules. Having to rebuild your modules for Electron with npm adds complexity to the workflow. Our team developed a module called [`prebuild`](http://npmjs.org/prebuild) which handles pre-built binaries, which worked well for Node, but Electron workflows still required a custom step after installing, usually `npm run rebuild`. It was annoying. To address this we recently switched to a strategy where we bundle all compiled binary versions of all platforms inside the npm tarball. This means tarballs get larger (though this can be optimized with `.so` files - shared libraries), this approach avoids having to run post-install scripts and also avoids the `npm run rebuild` pattern completely. It means `npm install` does the right thing for Electron the first time.
|
||||
|
||||
## What are your favorite things about Electron?
|
||||
|
||||
The APIs seem fairly well thought out, it's relatively stable, and it does a pretty good job at keeping up to date with upstream Node releases, not much else we can ask for!
|
||||
|
||||
## Any Electron tips that might be useful to other developers?
|
||||
|
||||
If you use native modules, give [prebuild](https://www.npmjs.com/package/prebuild) a shot!
|
||||
|
||||
## What's the best way to follow Dat developments?
|
||||
|
||||
Follow [@dat_project](https://twitter.com/dat_project) on Twitter, or
|
||||
subscribe to our [email newsletter](https://tinyletter.com/datdata).
|
||||
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
---
|
||||
title: Community Discord Server and Hacktoberfest
|
||||
author:
|
||||
- erickzhao
|
||||
date: '2020-10-01'
|
||||
---
|
||||
|
||||
Join us for community bonding and a month-long celebration of open-source.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
# Electron Community Discord Launch
|
||||
Electron’s [Outreach Working Group](https://github.com/electron/governance/tree/master/wg-outreach) is excited to
|
||||
announce the launch of our official community Discord server!
|
||||
|
||||
## Why a new Discord server?
|
||||
In its early days as the backbone of the [Atom text editor](https://atom.io/), community discussion on the Electron
|
||||
framework occurred in a single channel in Atom’s Slack workspace. As time passed and the two projects were increasingly
|
||||
decoupled, the relevance of the Atom workspace to the Electron project decreased, and maintainer participation in the
|
||||
Slack channel declined in the same manner.
|
||||
|
||||
Up until now, we had still been redirecting our broader community to the Atom Slack workspace, even though we’ve
|
||||
had many reports from folks who have had trouble receiving invitations, and few of our core maintainers were
|
||||
frequenting the channel.
|
||||
|
||||
We’re setting up this shiny new server to be a central discussion hub for the community where you can get the latest
|
||||
news on all things Electron.
|
||||
|
||||
## Get in here!
|
||||
So far, the server’s membership consists of a few maintainers who have been working together to set it up, but we’re
|
||||
so excited to chat with you all! Come ask for help, keep up to date with Electron releases, or just hang out with other
|
||||
developers. We’ve got a handy [invite for you](https://discord.gg/H6uTh7m) that’ll give you access to the server!
|
||||
|
||||
# Hacktoberfest 2020
|
||||
As a large and long-running open-source project, Electron wouldn’t have been nearly as successful without all the
|
||||
contributions from its community, from code submissions to bug reports to documentation changes, and much more.
|
||||
That’s why we believe in the importance of participating in Hacktoberfest to usher in a wider community of developers
|
||||
of all skill levels into the project.
|
||||
|
||||
## Odds and ends
|
||||
This year, we don’t have a wider project to give you all to work on, but we’d like to focus on opportunities to contribute
|
||||
across the Electron JavaScript ecosystem.
|
||||
|
||||
Look out for issues tagged [`hacktoberfest`](https://github.com/search?q=is%3Aissue+is%3Aopen+label%3Ahacktoberfest+org%3Aelectron+org%3Aelectron-userland)
|
||||
across our various repositories, including the main
|
||||
[electron/electron](https://github.com/electron/electron/issues?q=is%3Aopen+is%3Aissue+label%3A%22hacktoberfest%22+) repository,
|
||||
the [electron/electronjs.org](https://github.com/electron/electronjs.org/issues?q=is%3Aopen+is%3Aissue+label%3A%22hacktoberfest%22+) website,
|
||||
[electron/fiddle](https://github.com/electron/fiddle/issues?q=is%3Aopen+is%3Aissue+label%3A%22hacktoberfest%22+),
|
||||
and [electron-userland/electron-forge](https://github.com/electron-userland/electron-forge/issues?q=is%3Aopen+is%3Aissue+label%3A%22hacktoberfest%22+)!
|
||||
|
||||
P.S. If you're feeling particularly adventurous, we also have a backlog of issues marked with
|
||||
[`help wanted`](https://github.com/search?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+org%3Aelectron+org%3Aelectron-userland)
|
||||
tags if you're looking for more of a challenge.
|
||||
|
||||
## Stuck? Come chat with us!
|
||||
Moreover, it’s also no coincidence that the grand opening of our Discord server coincides with the largest celebration of
|
||||
open-source software of the year. Check out the #hacktoberfest channel to ask for help on your Hacktoberfest PR. In case
|
||||
you missed it, [here's the invite link again](https://discord.gg/H6uTh7m)!
|
||||
|
|
@ -1,119 +0,0 @@
|
|||
---
|
||||
title: Electron 1.0
|
||||
author: jlord
|
||||
date: '2016-05-11'
|
||||
---
|
||||
|
||||
For the last two years, Electron has helped developers build cross platform
|
||||
desktop apps using HTML, CSS, and JavaScript. Now we're excited to share a major
|
||||
milestone for our framework and for the community that created it. The release
|
||||
of Electron 1.0 is now available from [electronjs.org][electronjs.org].
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
Electron 1.0 represents a major milestone in API stability and maturity. This
|
||||
release allows you to build apps that act and feel truly native on Windows,
|
||||
Mac, and Linux. Building Electron apps is easier than ever with new docs,
|
||||
new tools, and a new app to walk you through the Electron APIs.
|
||||
|
||||
If you're ready to build your very first Electron app, here's a [quick start guide][quick-start]
|
||||
to help you get started.
|
||||
|
||||
We are excited to see what you build next with Electron.
|
||||
|
||||
## Electron's Path
|
||||
|
||||
We released Electron when we launched [Atom][atom] a little over two years ago.
|
||||
Electron, then known as Atom Shell, was the framework we'd built Atom on top of.
|
||||
In those days, Atom was the driving force behind the features and functionalities
|
||||
that Electron provided as we pushed to get the initial Atom release out.
|
||||
|
||||
Now driving Electron is a growing community of developers and companies building
|
||||
everything from [email][nylas], [chat][slack], and [Git apps][gitkraken] to
|
||||
[SQL analytics tools][wagon], [torrent clients][webtorrent], and [robots][jibo].
|
||||
|
||||
In these last two years we've seen both companies and open source projects
|
||||
choose Electron as the foundation for their apps. Just in the past year, Electron
|
||||
has been downloaded over 1.2 million times. [Take a tour][apps] of some
|
||||
of the amazing Electron apps and add your own if it isn't already there.
|
||||
|
||||
|
||||
|
||||
## Electron API Demos
|
||||
|
||||
Along with the 1.0 release, we're releasing a new app to help you explore the
|
||||
Electron APIs and learn more about how to make your Electron app feel native.
|
||||
The [Electron API Demos][electron-api-demos] app contains code snippets to help
|
||||
you get your app started and tips on effectively using the Electron APIs.
|
||||
|
||||
[][electron-api-demos]
|
||||
|
||||
## Devtron
|
||||
|
||||
We've also added a new extension to help you debug your Electron
|
||||
apps. [Devtron][devtron] is an open-source extension to the [Chrome Developer Tools][devtools]
|
||||
designed to help you inspect, debug, and troubleshoot your Electron app.
|
||||
|
||||
[][devtron]
|
||||
|
||||
### Features
|
||||
|
||||
* **Require graph** that helps you visualize your app's internal and external
|
||||
library dependencies in both the main and renderer processes
|
||||
* **IPC monitor** that tracks and displays the messages sent and received
|
||||
between the processes in your app
|
||||
* **Event inspector** that shows you the events and listeners that are registered
|
||||
in your app on the core Electron APIs such as the window, app, and processes
|
||||
* **App Linter** that checks your apps for common mistakes and missing
|
||||
functionality
|
||||
|
||||
## Spectron
|
||||
|
||||
Finally, we're releasing a new version of [Spectron][spectron], the integration
|
||||
testing framework for Electron apps.
|
||||
|
||||
[][spectron]
|
||||
|
||||
Spectron 3.0 has comprehensive support for the entire Electron API allowing you
|
||||
to more quickly write tests that verify your application's behavior in various
|
||||
scenarios and environments. Spectron is based on [ChromeDriver][chromedriver]
|
||||
and [WebDriverIO][webdriver] so it also has full APIs for page navigation, user
|
||||
input, and JavaScript execution.
|
||||
|
||||
## Community
|
||||
|
||||
Electron 1.0 is the result of a community effort by hundreds of developers.
|
||||
Outside of the core framework, there have been hundreds of libraries and tools
|
||||
released to make building, packaging, and deploying Electron apps easier.
|
||||
|
||||
There is now a new [community][community] page that lists many of the awesome
|
||||
Electron tools, apps, libraries, and frameworks being developed. You can also
|
||||
check out the [Electron][electron-org] and [Electron Userland][electron-userland]
|
||||
organizations to see some of these fantastic projects.
|
||||
|
||||
New to Electron? Watch the Electron 1.0 intro video:
|
||||
|
||||
<div class="video"><iframe src="https://www.youtube.com/embed/8YP_nOCO-4Q?rel=0" frameborder="0" allowfullscreen></iframe></div>
|
||||
|
||||
[apps]: https://electronjs.org/apps
|
||||
[atom]: https://atom.io
|
||||
[chromedriver]: https://sites.google.com/a/chromium.org/chromedriver
|
||||
[community]: https://electronjs.org/community
|
||||
[devtools]: https://developer.chrome.com/devtools
|
||||
[devtron]: https://electronjs.org/devtron
|
||||
[electronjs.org]: https://electronjs.org
|
||||
[electron-api-demos]: https://github.com/electron/electron-api-demos
|
||||
[electron-org]: https://github.com/electron
|
||||
[electron-userland]: https://github.com/electron-userland
|
||||
[gitkraken]: https://www.gitkraken.com
|
||||
[jibo]: https://www.jibo.com
|
||||
[nylas]: https://nylas.com
|
||||
[quick-start]: https://electronjs.org/docs/tutorial/quick-start
|
||||
[slack]: https://slack.com
|
||||
[spectron]: https://electronjs.org/spectron
|
||||
[wagon]: https://www.wagonhq.com
|
||||
[webtorrent]: https://webtorrent.io/desktop
|
||||
[webdriver]: http://webdriver.io
|
||||
|
||||
|
|
@ -1,80 +0,0 @@
|
|||
---
|
||||
title: Electron 10.0.0
|
||||
author:
|
||||
- VerteDinde
|
||||
- sofianguy
|
||||
date: '2020-08-25'
|
||||
---
|
||||
|
||||
Electron 10.0.0 has been released! It includes upgrades to Chromium `85`, V8 `8.5`, and Node.js `12.16`. We've added several new API integrations and improvements. Read below for more details!
|
||||
|
||||
---
|
||||
|
||||
The Electron team is excited to announce the release of Electron 10.0.0! You can install it with npm via `npm install electron@latest` or download it from our [releases website](https://electronjs.org/releases/stable). The release is packed with upgrades, fixes, and new features.
|
||||
|
||||
In the Electron 10 release, we also made a change to our release notes. To make it easier to tell what's brand new in Electron 10 and what may have changed between Electron 10 and past releases, we now also include changes that were introduced to Electron 10, but backported to previous releases. We hope this makes it easier to apps to find new features and bug fixes when upgrading Electron.
|
||||
|
||||
We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
|
||||
|
||||
## Notable Changes
|
||||
|
||||
### Stack Changes
|
||||
|
||||
* Chromium `85.0.4183.84`
|
||||
* [New in Chrome 84](https://developers.google.com/web/updates/2020/07/nic84)
|
||||
* [New in Chrome 85](https://chromereleases.googleblog.com/2020/08/stable-channel-update-for-desktop_25.html)
|
||||
* Node.js `12.16.3`
|
||||
* [Node 12.16.3 blog post](https://nodejs.org/en/blog/release/v12.16.3/)
|
||||
* V8 `8.5`
|
||||
* [V8 8.4 blog post](https://v8.dev/blog/v8-release-84)
|
||||
* [V8 8.5 blog post](https://v8.dev/blog/v8-release-85)
|
||||
|
||||
### Highlight Features
|
||||
|
||||
* Added `contents.getBackgroundThrottling()` method and `contents.backgroundThrottling` property. [#21036]
|
||||
* Exposed the `desktopCapturer` module in the main process. [#23548](https://github.com/electron/electron/pull/23548)
|
||||
* Can now check if a given `session` is persistent by calling the `ses.isPersistent()` API. [#22622](https://github.com/electron/electron/pull/22622)
|
||||
* Resolve network issues that prevented RTC calls from being connected due to network IP address changes and ICE. (Chromium issue 1113227). [#24998](https://github.com/electron/electron/pull/24998)
|
||||
|
||||
See the [10.0.0 release notes](https://github.com/electron/electron/releases/tag/v10.0.0) for a full list of new features and changes.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
* Changed the default value of `enableRemoteModule` to `false`. [#22091](https://github.com/electron/electron/pull/22091)
|
||||
* This is part of our plans for deprecating the `remote` module and moving it to userland. You can read and follow [this issue](https://github.com/electron/electron/issues/21408) that details our reasons for this and includes a proposed timeline for deprecation.
|
||||
* Changed the default value of `app.allowRendererProcessReuse` to `true`. [#22336](https://github.com/electron/electron/pull/22336) (Also in [Electron 9](https://github.com/electron/electron/pull/22401))
|
||||
* This will prevent loading of non-context-aware native modules in renderer processes.
|
||||
* You can read and follow [this issue](https://github.com/electron/electron/issues/18397) that details our reasons for this and includes a proposed timeline for deprecation.
|
||||
* Fixed the positioning of window buttons on macOS when the OS locale is set to an RTL language (like Arabic or Hebrew). Frameless window apps may have to account for this change while styling their windows. [#22016](https://github.com/electron/electron/pull/22016)
|
||||
|
||||
More information about these and future changes can be found on the [Planned Breaking Changes](https://github.com/electron/electron/blob/master/docs/breaking-changes.md) page.
|
||||
|
||||
## API Changes
|
||||
|
||||
* Session: Can now check if a given `session` is persistent by calling the `ses.isPersistent()` API. [#22622](https://github.com/electron/electron/pull/22622)
|
||||
* Contents: Added `contents.getBackgroundThrottling()` method and `contents.backgroundThrottling` property. [#21036](https://github.com/electron/electron/pull/21036)
|
||||
|
||||
### Deprecated APIs
|
||||
|
||||
The following APIs are now deprecated or removed:
|
||||
|
||||
* Removed the deprecated `currentlyLoggingPath` property of `netLog`. Additionally, `netLog.stopLogging` no longer returns the path to the recorded log. [#22732](https://github.com/electron/electron/pull/22732)
|
||||
* Deprecated uncompressed crash uploads in `crashReporter`. [#23598](https://github.com/electron/electron/pull/23598)
|
||||
|
||||
## End of Support for 7.x.y
|
||||
|
||||
Electron 7.x.y has reached end-of-support as per the project's [support policy](https://electronjs.org/docs/tutorial/support#supported-versions). Developers and applications are encouraged to upgrade to a newer version of Electron.
|
||||
|
||||
## What's Next
|
||||
|
||||
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The [tentative 11.0.0 schedule](https://electronjs.org/docs/tutorial/electron-timelines) maps out key dates in the Electron 11.0 development life cycle. Also, [see our versioning document](https://electronjs.org/docs/tutorial/electron-versioning) for more detailed information about versioning in Electron.
|
||||
|
||||
For information on planned breaking changes in upcoming versions of Electron, [see our Planned Breaking Changes doc](https://github.com/electron/electron/blob/master/docs/breaking-changes.md).
|
||||
|
||||
### Continued Work for Deprecation of `remote` Module (in Electron 11)
|
||||
We started work to remove the remote module in [Electron 9](https://www.electronjs.org/blog/electron-9-0) and we're continuing plans to remove the `remote` module. In Electron 11, we plan to continue refactor work for implementing [WeakRef](https://v8.dev/features/weak-references) as we have done in Electron 10. Please read and follow [this issue](https://github.com/electron/electron/issues/21408) for full plans and details for deprecation.
|
||||
|
||||
### Final Step for Requiring Native Node Modules to be Context Aware or N-API (in Electron 12)
|
||||
_Edit: Originally, this blog post stated that we would disable renderer process reuse in Electron 11. Disabling renderer process reuse has now been pushed to Electron 12._
|
||||
|
||||
From Electron 6 onwards, we've been laying the groundwork to require [native Node modules](https://nodejs.org/api/addons.html) loaded in the renderer process to be either [N-API](https://nodejs.org/api/n-api.html) or [Context Aware](https://nodejs.org/api/addons.html#addons_context_aware_addons). Enforcing this change allows for stronger security, faster performance, and reduced maintenance workload. The final step of this plan is to remove the ability to disable render process reuse in Electron 12. Read [this issue](https://github.com/electron/electron/issues/18397) for full details including the proposed timeline.
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
---
|
||||
title: Electron 11.0.0
|
||||
author:
|
||||
- VerteDinde
|
||||
date: '2020-11-17'
|
||||
---
|
||||
|
||||
Electron 11.0.0 has been released! It includes upgrades to Chromium `87`, V8 `8.7`, and Node.js `12.18.3`. We've added support for Apple silicon, and general improvements. Read below for more details!
|
||||
|
||||
---
|
||||
|
||||
The Electron team is excited to announce the release of Electron 11.0.0! You can install it with npm via `npm install electron@latest` or download it from our [releases website](https://electronjs.org/releases/stable). The release is packed with upgrades, fixes, and new support for Apple's M1 hardware.
|
||||
|
||||
We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
|
||||
|
||||
## Notable Changes
|
||||
|
||||
### Stack Changes
|
||||
|
||||
* Chromium `87.0.4280.47`
|
||||
* [New in Chrome 86](https://developers.google.com/web/updates/2020/10/nic86)
|
||||
* [New in Chrome 87](https://developers.google.com/web/updates/2020/11/nic87)
|
||||
* Node.js `12.18.3`
|
||||
* [Node 12.18.3 blog post](https://nodejs.org/en/blog/release/v12.18.3/)
|
||||
* [Node 12.7.0 blog post](https://nodejs.org/en/blog/release/v12.17.0/)
|
||||
* V8 `8.7`
|
||||
* [V8 8.6 blog post](https://v8.dev/blog/v8-release-86)
|
||||
* [V8 8.7 blog post](https://v8.dev/blog/v8-release-87)
|
||||
|
||||
### Highlight Features
|
||||
|
||||
* Support for Apple M1: On November 10, Apple announced their [new M1 chips, which will be included in their upcoming hardware](https://www.apple.com/newsroom/2020/11/apple-unleashes-m1/). Beginning in Electron 11, Electron will be shipping separate versions of Electron for Intel Macs (x64) and Apple's upcoming M1 hardware (arm64). You can learn more about how to get your Electron app [running on Apple's M1 hardware here.](https://www.electronjs.org/blog/apple-silicon) [#24545](https://github.com/electron/electron/pull/24545)
|
||||
* Added V8 crash message and location information to crashReport parameters. [#24771](https://github.com/electron/electron/pull/24771)
|
||||
* Improved the performance of sending wide objects over the context bridge. [#24671](https://github.com/electron/electron/pull/24671)
|
||||
|
||||
See the [11.0.0 release notes](https://github.com/electron/electron/releases/tag/v11.0.0) for a full list of new features and changes.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
* Removed experimental APIs: `BrowserView.{fromId, fromWebContents, getAllViews}` and the `id` property of `BrowserView`. [#23578](https://github.com/electron/electron/pull/23578)
|
||||
|
||||
More information about these and future changes can be found on the [Planned Breaking Changes](https://github.com/electron/electron/blob/master/docs/breaking-changes.md) page.
|
||||
|
||||
## API Changes
|
||||
|
||||
* Added `app.getApplicationInfoForProtocol()` API that returns detailed information about the app that handles a certain protocol. [#24112](https://github.com/electron/electron/pull/24112)
|
||||
* Added `app.createThumbnailFromPath()` API that returns a preview image of a file given its file path and a maximum thumbnail size. [#24802](https://github.com/electron/electron/pull/24802)
|
||||
* Added `webContents.forcefullyCrashRenderer()` to forcefully terminate a renderer process to assist with recovering a hung renderer. [#25756](https://github.com/electron/electron/pull/25756)
|
||||
|
||||
## End of Support for 8.x.y
|
||||
|
||||
Electron 8.x.y has reached end-of-support as per the project's [support policy](https://electronjs.org/docs/tutorial/support#supported-versions). Developers and applications are encouraged to upgrade to a newer version of Electron.
|
||||
|
||||
## What's Next
|
||||
|
||||
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately quarterly. The [tentative 12.0.0 schedule](https://electronjs.org/docs/tutorial/electron-timelines) maps out key dates in the Electron 12.0 development life cycle. Also, [see our versioning document](https://electronjs.org/docs/tutorial/electron-versioning) for more detailed information about versioning in Electron.
|
||||
|
||||
For information on planned breaking changes in upcoming versions of Electron, [see our Planned Breaking Changes doc](https://github.com/electron/electron/blob/master/docs/breaking-changes.md).
|
||||
|
||||
### Continued Work for Deprecation of `remote` Module
|
||||
We started work to remove the `remote` module in [Electron 9](https://www.electronjs.org/blog/electron-9-0). We plan to remove the `remote` module itself in Electron 14.
|
||||
|
||||
Read and follow [this issue](https://github.com/electron/electron/issues/21408) for full plans and details for deprecation.
|
||||
|
||||
### Final Step for Requiring Native Node Modules to be Context Aware or N-API (in Electron 12)
|
||||
From Electron 6 onwards, we've been laying the groundwork to require [native Node modules](https://nodejs.org/api/addons.html) loaded in the renderer process to be either [N-API](https://nodejs.org/api/n-api.html) or [Context Aware](https://nodejs.org/api/addons.html#addons_context_aware_addons). Enforcing this change allows for stronger security, faster performance, and reduced maintenance workload. The final step of this plan is to remove the ability to disable render process reuse in Electron 12.
|
||||
|
||||
Read and follow [this issue](https://github.com/electron/electron/issues/18397) for full details, including the proposed timeline.
|
||||
|
|
@ -1,113 +0,0 @@
|
|||
---
|
||||
title: Electron 12.0.0
|
||||
author:
|
||||
- VerteDinde
|
||||
- mlaurencin
|
||||
- sofianguy
|
||||
date: '2021-03-02'
|
||||
---
|
||||
|
||||
Electron 12.0.0 has been released! It includes upgrades to Chromium `89`, V8 `8.9` and Node.js `14.16`. We've added changes to the remote module, new defaults for contextIsolation, a new webFrameMain API, and general improvements. Read below for more details!
|
||||
|
||||
---
|
||||
|
||||
The Electron team is excited to announce the release of Electron 12.0.0! You can install it with npm via `npm install electron@latest` or download it from our [releases website](https://electronjs.org/releases/stable). Continue reading for details about this release, and please share any feedback you have!
|
||||
|
||||
## Notable Changes
|
||||
|
||||
### Stack Changes
|
||||
|
||||
* Chromium `89`
|
||||
* [New in Chrome 88](https://developer.chrome.com/blog/new-in-chrome-88/)
|
||||
* [New in Chrome 89](https://developer.chrome.com/blog/new-in-chrome-89/)
|
||||
* Node.js `14.16`
|
||||
* [Node 14.16.0 blog post](https://nodejs.org/en/blog/release/v14.16.0/)
|
||||
* [Node 14.0.0 blog post](https://nodejs.org/en/blog/release/v14.0.0/)
|
||||
* V8 `8.9`
|
||||
* [V8 8.8 blog post](https://v8.dev/blog/v8-release-88)
|
||||
* [V8 8.9 blog post](https://v8.dev/blog/v8-release-89)
|
||||
|
||||
### Highlight Features
|
||||
|
||||
* The ContextBridge `exposeInMainWorld` method can now expose non-object APIs. [#26834](https://github.com/electron/electron/pull/26834)
|
||||
* Upgraded from Node 12 to Node 14. [#23249](https://github.com/electron/electron/pull/25249)
|
||||
* Added a new `webFrameMain` API for accessing sub-frames of a `WebContents` instance from the main process. [#25464](https://github.com/electron/electron/pull/25464)
|
||||
* The default values of `contextIsolation` and `worldSafeExecuteJavaScript` are now `true`. [#27949](https://github.com/electron/electron/pull/27949) [#27502](https://github.com/electron/electron/pull/27502)
|
||||
|
||||
See the [12.0.0 release notes](https://github.com/electron/electron/releases/tag/v12.0.0) for a full list of new features and changes.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
* Deprecated the `remote` module. It is replaced by [`@electron/remote`](https://github.com/electron/remote). [#25293](https://github.com/electron/electron/pull/25293)
|
||||
* If you are currently using the `remote` module, we've written [a guide to migrating to `@electron/remote` here.](https://github.com/electron/remote#migrating-from-remote)
|
||||
* Changed the default value of `contextIsolation` to `true`. [#27949](https://github.com/electron/electron/pull/27949)
|
||||
* Changed the default value of `worldSafeExecuteJavaScript` to `true`. [#27502](https://github.com/electron/electron/pull/27502)
|
||||
* Changed the default of `crashReporter.start({ compress })` from `false` to `true`. [#25288](https://github.com/electron/electron/pull/25288)
|
||||
* Removed Flash support: Chromium has removed support for Flash, which was also removed in Electron 12. See [Chromium's Flash Roadmap](https://www.chromium.org/flash-roadmap) for more details.
|
||||
* Required SSE3 for Chrome on x86: Chromium has removed support for [older x86 CPUs that do not meet a minimum of SSE3 (Streaming SIMD Extensions 3) support](https://docs.google.com/document/d/1QUzL4MGNqX4wiLvukUwBf6FdCL35kCDoEJTm2wMkahw/edit#heading=h.7nki9mck5t64). This support was also removed in Electron 12.
|
||||
|
||||
More information about these and future changes can be found on the [Planned Breaking Changes](https://github.com/electron/electron/blob/master/docs/breaking-changes.md) page.
|
||||
|
||||
## API Changes
|
||||
|
||||
* Added `webFrameMain` API: The `webFrameMain` module can be used to look up frames across existing [`WebContents`](/docs/api/web-contents.md) instances. This is the main process equivalent of the existing webFrame API. More information about this new API can be found [here](https://github.com/electron/electron/pull/25464), and in our [documentation](https://www.electronjs.org/docs/api/web-frame-main).
|
||||
* `app` API changes:
|
||||
* Added non-localized `serviceName` to `'child-process-gone'` / `app.getAppMetrics()`. [#25975](https://github.com/electron/electron/pull/25975)
|
||||
* Added new `app.runningUnderRosettaTranslation` property to detect when running under rosetta on Apple silicon. [#26444](https://github.com/electron/electron/pull/26444)
|
||||
* Added `exitCode` to `render-process-gone` details (app & webContents). [#27677](https://github.com/electron/electron/pull/27677)
|
||||
* `BrowserWindow` API changes:
|
||||
* Added `BrowserWindow.isTabletMode()` API. [#25209](https://github.com/electron/electron/pull/25209)
|
||||
* Added `resized` (Windows/macOS) and `moved` (Windows) events to `BrowserWindow`. [#26216](https://github.com/electron/electron/pull/26216)
|
||||
* Added new `system-context-menu` event to allow preventing and overriding the system context menu. [#25795](https://github.com/electron/electron/pull/25795)
|
||||
* Added `win.setTopBrowserView()` so that `BrowserView`s can be raised. [#27713](https://github.com/electron/electron/pull/27713)
|
||||
* Added `webPreferences.preferredSizeMode` to allow sizing views according to their document's minimum size. [#25874](https://github.com/electron/electron/pull/25874)
|
||||
* `contextBridge` API changes:
|
||||
* Allowed ContextBridge `exposeInMainWorld` method to expose non-object APIs. [#26834](https://github.com/electron/electron/pull/26834)
|
||||
* `display` API changes:
|
||||
* Added `displayFrequency` property to the `Display` object to allow getting information about the refresh rate on Windows. [#26472](https://github.com/electron/electron/pull/26472)
|
||||
* `extensions` API changes:
|
||||
* Added support for some `chrome.management` APIs. [#25098](https://github.com/electron/electron/pull/25098)
|
||||
* `MenuItem` API changes:
|
||||
* Added support for showing macOS share menu. [#25629](https://github.com/electron/electron/pull/25629)
|
||||
* `net` API changes:
|
||||
* Added a new `credentials` option for `net.request()`. [#25284](https://github.com/electron/electron/pull/25284)
|
||||
* Added `net.online` for detecting whether there is currently internet connection. [#21004](https://github.com/electron/electron/pull/21004)
|
||||
* `powerMonitor` API changes:
|
||||
* Added `powerMonitor.onBatteryPower`. [#26494](https://github.com/electron/electron/pull/26494)
|
||||
* Added fast user switching event to powerMonitor on macOS. [#25321](https://github.com/electron/electron/pull/25321)
|
||||
* `session` API changes:
|
||||
* Added `allowFileAccess` option to `ses.loadExtension()` API. [#27702](https://github.com/electron/electron/pull/27702)
|
||||
* Added `display-capture` API for `session.setPermissionRequestHandler`. [#27696](https://github.com/electron/electron/pull/27696)
|
||||
* Added a `disabledCipherSuites` option to `session.setSSLConfig`. [#25818](https://github.com/electron/electron/pull/25818)
|
||||
* Added `extension-loaded`, `extension-unloaded`, and `extension-ready` events to `session`. [#25385](https://github.com/electron/electron/pull/25385)
|
||||
* Added `session.setSSLConfig()` to allow configuring SSL. [#25461](https://github.com/electron/electron/pull/25461)
|
||||
* Added support for explicitly specifying `direct`, `auto_detect` or `system` modes in `session.setProxy()`. [#24937](https://github.com/electron/electron/pull/24937)
|
||||
* Added [Serial API](https://web.dev/serial/) support. [#25237](https://github.com/electron/electron/pull/25237)
|
||||
* Added APIs to enable/disable spell checker. [#26276](https://github.com/electron/electron/pull/26276)
|
||||
* `shell` API changes:
|
||||
* Added a new asynchronous `shell.trashItem()` API, replacing the synchronous `shell.moveItemToTrash()`. [#25114](https://github.com/electron/electron/pull/25114)
|
||||
* `webContents` API changes:
|
||||
* Added a small console hint to console to help debug renderer crashes. [#25317](https://github.com/electron/electron/pull/25317)
|
||||
* Added `frame` and `webContents` properties to the details object in webRequest handlers. [#27334](https://github.com/electron/electron/pull/27334)
|
||||
* Added `webContents.forcefullyCrashRenderer()` to forcefully terminate a renderer process to assist with recovering a hung renderer. [#25580](https://github.com/electron/electron/pull/25580)
|
||||
* Added `setWindowOpenHandler` API for renderer-created child windows, and deprecate `new-window` event. [#24517](https://github.com/electron/electron/pull/24517)
|
||||
* `webFrame` API changes:
|
||||
* Added spellcheck API to renderer. [#25060](https://github.com/electron/electron/pull/25060)
|
||||
|
||||
### Removed/Deprecated Changes
|
||||
|
||||
The following APIs have been removed or are now deprecated:
|
||||
|
||||
* Deprecated the `remote` module. It is replaced by [`@electron/remote`](https://github.com/electron/remote). [#25293](https://github.com/electron/electron/pull/25293)
|
||||
* Removed deprecated `crashReporter` APIs. [#26709](https://github.com/electron/electron/pull/26709)
|
||||
* Removed links to the Electron website from the default 'Help' menu in packaged apps. [#25831](https://github.com/electron/electron/pull/25831)
|
||||
|
||||
## End of Support for 9.x.y
|
||||
|
||||
Electron 9.x.y has reached end-of-support as per the project's [support policy](https://electronjs.org/docs/tutorial/support#supported-versions). Developers and applications are encouraged to upgrade to a newer version of Electron.
|
||||
|
||||
## What's Next
|
||||
|
||||
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The [tentative 13.0.0 schedule](https://electronjs.org/docs/tutorial/electron-timelines) maps out key dates in the Electron 13.0 development life cycle. Also, [see our versioning document](https://electronjs.org/docs/tutorial/electron-versioning) for more detailed information about versioning in Electron.
|
||||
|
||||
For information on planned breaking changes in upcoming versions of Electron, [see our Planned Breaking Changes doc](https://github.com/electron/electron/blob/master/docs/breaking-changes.md).
|
||||
|
|
@ -1,118 +0,0 @@
|
|||
---
|
||||
title: Electron 2.0.0
|
||||
author: ckerr
|
||||
date: '2018-05-02'
|
||||
---
|
||||
|
||||
After more than four months of development, eight beta releases, and worldwide
|
||||
testing from many apps' staged rollouts, the release of Electron 2.0.0 is now
|
||||
available from [electronjs.org](https://electronjs.org/).
|
||||
|
||||
---
|
||||
|
||||
## Release Process
|
||||
|
||||
Starting with 2.0.0, Electron's releases will follow [semantic versioning](https://electronjs.org/blog/electron-2-semantic-boogaloo). This means the major version will bump more often and will usually be a major update to Chromium. Patch releases should be more stable because they will contain only high-priority bug fixes.
|
||||
|
||||
Electron 2.0.0 also represents an improvement to how Electron is stabilized before a major release. Several large scale Electron apps have included 2.0.0 betas in staged rollouts, providing the best feedback loop Electron's ever had for a beta series.
|
||||
|
||||
## Changes / New Features
|
||||
|
||||
* Major bumps to several important parts of Electron's toolchain, including Chrome 61, Node 8.9.3, V8 6.1.534.41, GTK+ 3 on Linux, updated spellchecker, and Squirrel.
|
||||
* [In-app purchases](https://electronjs.org/blog/in-app-purchases)
|
||||
are now supported on MacOS. [#11292](https://github.com/electron/electron/pull/11292)
|
||||
* New API for loading files. [#11565](https://github.com/electron/electron/pull/11565)
|
||||
* New API to enable/disable a window. [#11832](https://github.com/electron/electron/pull/11832)
|
||||
* New API app.setLocale(). [#11469](https://github.com/electron/electron/pull/11469)
|
||||
* New support for logging IPC messages. [#11880](https://github.com/electron/electron/pull/11880)
|
||||
* New menu events. [#11754](https://github.com/electron/electron/pull/11754)
|
||||
* Add a `shutdown` event to powerMonitor. [#11417](https://github.com/electron/electron/pull/11417)
|
||||
* Add `affinity` option for gathering several BrowserWindows into a single process. [#11501](https://github.com/electron/electron/pull/11501)
|
||||
* Add the ability for saveDialog to list available extensions. [#11873](https://github.com/electron/electron/pull/11873)
|
||||
* Support for additional notification actions [#11647](https://github.com/electron/electron/pull/11647)
|
||||
* The ability to set macOS notification close button title. [#11654](https://github.com/electron/electron/pull/11654)
|
||||
* Add conditional for menu.popup(window, callback)
|
||||
* Memory improvements in touchbar items. [#12527](https://github.com/electron/electron/pull/12527)
|
||||
* Improved security recommendation checklist.
|
||||
* Add App-Scoped Security scoped bookmarks. [#11711](https://github.com/electron/electron/pull/11711)
|
||||
* Add ability to set arbitrary arguments in a renderer process. [#11850](https://github.com/electron/electron/pull/11850)
|
||||
* Add accessory view for format picker. [#11873](https://github.com/electron/electron/pull/11873)
|
||||
* Fixed network delegate race condition. [#12053](https://github.com/electron/electron/pull/12053)
|
||||
* Drop support for the `mips64el` arch on Linux. Electron requires the C++14 toolchain, which was
|
||||
not available for that arch at the time of the release. We hope to re-add support in the future.
|
||||
|
||||
## Breaking API changes
|
||||
|
||||
* Removed [deprecated APIs](https://github.com/electron/electron/blob/v2.0.0-beta.8/docs/tutorial/planned-breaking-changes.md), including:
|
||||
* Changed `menu.popup` signature. [#11968](https://github.com/electron/electron/pull/11968)
|
||||
* Removed deprecated `crashReporter.setExtraParameter` [#11972](https://github.com/electron/electron/pull/11972)
|
||||
* Removed deprecated `webContents.setZoomLevelLimits` and `webFrame.setZoomLevelLimits`. [#11974](https://github.com/electron/electron/pull/11974)
|
||||
* Removed deprecated `clipboard` methods. [#11973](https://github.com/electron/electron/pull/11973)
|
||||
* Removed support for boolean parameters for `tray.setHighlightMode`. [#11981](https://github.com/electron/electron/pull/11981)
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
* Changed to make sure `webContents.isOffscreen()` is always available. [#12531](https://github.com/electron/electron/pull/12531)
|
||||
* Fixed `BrowserWindow.getFocusedWindow()` when DevTools is undocked and focused. [#12554](https://github.com/electron/electron/pull/12554)
|
||||
* Fixed preload not loading in sandboxed render if preload path contains special chars. [#12643](https://github.com/electron/electron/pull/12643)
|
||||
* Correct the default of allowRunningInsecureContent as per docs. [#12629](https://github.com/electron/electron/pull/12629)
|
||||
* Fixed transparency on nativeImage. [#12683](https://github.com/electron/electron/pull/12683)
|
||||
* Fixed issue with `Menu.buildFromTemplate`. [#12703](https://github.com/electron/electron/pull/12703)
|
||||
* Confirmed menu.popup options are objects. [#12330](https://github.com/electron/electron/pull/12330)
|
||||
* Removed a race condition between new process creation and context release. [#12361](https://github.com/electron/electron/pull/12361)
|
||||
* Update draggable regions when changing BrowserView. [#12370](https://github.com/electron/electron/pull/12370)
|
||||
* Fixed menubar toggle alt key detection on focus. [#12235](https://github.com/electron/electron/pull/12235)
|
||||
* Fixed incorrect warnings in webviews. [#12236](https://github.com/electron/electron/pull/12236)
|
||||
* Fixed inheritance of 'show' option from parent windows. [#122444](https://github.com/electron/electron/pull/122444)
|
||||
* Ensure that `getLastCrashReport()` is actually the last crash report. [#12255](https://github.com/electron/electron/pull/12255)
|
||||
* Fixed require on network share path. [#12287](https://github.com/electron/electron/pull/12287)
|
||||
* Fixed context menu click callback. [#12170](https://github.com/electron/electron/pull/12170)
|
||||
* Fixed popup menu position. [#12181](https://github.com/electron/electron/pull/12181)
|
||||
* Improved libuv loop cleanup. [#11465](https://github.com/electron/electron/pull/11465)
|
||||
* Fixed `hexColorDWORDToRGBA` for transparent colors. [#11557](https://github.com/electron/electron/pull/11557)
|
||||
* Fixed null pointer dereference with getWebPreferences api. [#12245](https://github.com/electron/electron/pull/12245)
|
||||
* Fixed a cyclic reference in menu delegate. [#11967](https://github.com/electron/electron/pull/11967)
|
||||
* Fixed protocol filtering of net.request. [#11657](https://github.com/electron/electron/pull/11657)
|
||||
* WebFrame.setVisualZoomLevelLimits now sets user-agent scale constraints [#12510](https://github.com/electron/electron/pull/12510)
|
||||
* Set appropriate defaults for webview options. [#12292](https://github.com/electron/electron/pull/12292)
|
||||
* Improved vibrancy support. [#12157](https://github.com/electron/electron/pull/12157) [#12171](https://github.com/electron/electron/pull/12171) [#11886](https://github.com/electron/electron/pull/11886)
|
||||
* Fixed timing issue in singleton fixture.
|
||||
* Fixed broken production cache in NotifierSupportsActions()
|
||||
* Made MenuItem roles camelCase-compatible. [#11532](https://github.com/electron/electron/pull/11532)
|
||||
* Improved touch bar updates. [#11812](https://github.com/electron/electron/pull/11812), [#11761](https://github.com/electron/electron/pull/11761).
|
||||
* Removed extra menu separators. [#11827](https://github.com/electron/electron/pull/11827)
|
||||
* Fixed Bluetooth chooser bug. Closes [#11399](https://github.com/electron/electron/pull/11399).
|
||||
* Fixed macos Full Screen Toggle menu item label. [#11633](https://github.com/electron/electron/pull/11633)
|
||||
* Improved tooltip hiding when a window is deactivated. [#11644](https://github.com/electron/electron/pull/11644)
|
||||
* Migrated deprecated web-view method. [#11798](https://github.com/electron/electron/pull/11798)
|
||||
* Fixed closing a window opened from a browserview. [#11799](https://github.com/electron/electron/pull/11799)
|
||||
* Fixed Bluetooth chooser bug. [#11492](https://github.com/electron/electron/pull/11492)
|
||||
* Updated to use task scheduler for app.getFileIcon API. [#11595](https://github.com/electron/electron/pull/11595)
|
||||
* Changed to fire `console-message` event even when rendering offscreen. [#11921](https://github.com/electron/electron/pull/11921)
|
||||
* Fixed downloading from custom protocols using `WebContents.downloadURL`. [#11804](https://github.com/electron/electron/pull/11804)
|
||||
* Fixed transparent windows losing transparency when devtools detaches. [#11956](https://github.com/electron/electron/pull/11956)
|
||||
* Fixed Electron apps canceling restart or shutdown. [#11625](https://github.com/electron/electron/pull/11625)
|
||||
|
||||
### macOS
|
||||
* Fixed event leak on reuse of touchbar item. [#12624](https://github.com/electron/electron/pull/12624)
|
||||
* Fixed tray highlight in darkmode. [#12398](https://github.com/electron/electron/pull/12398)
|
||||
* Fixed blocking main process for async dialog. [#12407](https://github.com/electron/electron/pull/12407)
|
||||
* Fixed `setTitle` tray crash. [#12356](https://github.com/electron/electron/pull/12356)
|
||||
* Fixed crash when setting dock menu. [#12087](https://github.com/electron/electron/pull/12087)
|
||||
|
||||
### Linux
|
||||
* Better Linux desktop notifications. [#12229](https://github.com/electron/electron/pull/12229) [#12216](https://github.com/electron/electron/pull/12216) [#11965](https://github.com/electron/electron/pull/11965) [#11980](https://github.com/electron/electron/pull/11980)
|
||||
* Better GTK+ theme support for menus. [#12331](https://github.com/electron/electron/pull/12331)
|
||||
* Exit gracefully on linux. [#12139](https://github.com/electron/electron/pull/12139)
|
||||
* Use the app’s name as the tray icon's default tooltip. [#12393](https://github.com/electron/electron/pull/12393)
|
||||
|
||||
### Windows
|
||||
* Added Visual Studio 2017 support. [#11656](https://github.com/electron/electron/pull/11656)
|
||||
* Fixed passing of exception to the system crash handler. [#12259](https://github.com/electron/electron/pull/12259)
|
||||
* Fixed hiding tooltip from minimized window. [#11644](https://github.com/electron/electron/pull/11644)
|
||||
* Fixed `desktopCapturer` to capture the correct screen. [#11664](https://github.com/electron/electron/pull/11664)
|
||||
* Fixed `disableHardwareAcceleration` with transparency. [#11704](https://github.com/electron/electron/pull/11704)
|
||||
|
||||
# What's Next
|
||||
|
||||
The Electron team is hard at work to support newer versions of Chromium, Node, and v8. Expect 3.0.0-beta.1 soon!
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
title: 'Electron 2.0 and Beyond - Semantic Versioning'
|
||||
author: groundwater
|
||||
date: '2017-12-06'
|
||||
---
|
||||
|
||||
A new major version of Electron is in the works, and with it some changes to our versioning strategy. As of version 2.0.0, Electron will strictly adhere to Semantic Versioning.
|
||||
|
||||
---
|
||||
|
||||
This change means you'll see the major version bump more often, and it will usually be a major update to Chromium. Patch releases will also be more stable, as they will now only contain bug fixes with no new features.
|
||||
|
||||
**Major Version Increments**
|
||||
|
||||
* Chromium version updates
|
||||
* Node.js major version updates
|
||||
* Electron breaking API changes
|
||||
|
||||
**Minor Version Increments**
|
||||
|
||||
* Node.js minor version updates
|
||||
* Electron non-breaking API changes
|
||||
|
||||
**Patch Version Increments**
|
||||
|
||||
* Node.js patch version updates
|
||||
* fix-related chromium patches
|
||||
* Electron bug fixes
|
||||
|
||||
Because Electron's semver ranges will now be more meaningful, we recommend
|
||||
installing Electron using npm's default `--save-dev` flag, which will prefix
|
||||
your version with `^`, keeping you safely up to date with minor and patch
|
||||
updates:
|
||||
|
||||
```sh
|
||||
npm install --save-dev electron
|
||||
```
|
||||
|
||||
For developers interested only in bug fixes, you should use the tilde semver prefix e.g. `~2.0.0`, which which will never introduce new features, only fixes to improve stability.
|
||||
|
||||
For more details, see [electronjs.org/docs/tutorial/electron-versioning](https://electronjs.org/docs/tutorial/electron-versioning).
|
||||
|
|
@ -1,96 +0,0 @@
|
|||
---
|
||||
title: Electron 3.0.0
|
||||
author: codebytere
|
||||
date: '2018-09-18'
|
||||
---
|
||||
|
||||
The Electron team is excited to announce that the first stable release of Electron 3 is now
|
||||
available from [electronjs.org](https://electronjs.org/) and via `npm install electron@latest`! It's jam-packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Below are details about this release, and we welcome your feedback as you explore.
|
||||
|
||||
---
|
||||
|
||||
## Release Process
|
||||
|
||||
As we undertook development of `v3.0.0`, we sought to more empirically define criteria for a stable release by formalizing the feedback progress for progressive beta releases. `v3.0.0` would not have been possible without our [App Feedback Program](https://github.com/electron/electron/blob/3-0-x/docs/tutorial/app-feedback-program.md) partners, who provided early testing and feedback during the beta cycle. Thanks to Atlassian, Atom, Microsoft Teams, Oculus, OpenFin, Slack, Symphony, VS Code, and other program members for their work. If you'd like to participate in future betas, please mail us at [info@electronjs.org](mailto:info@electronjs.org).
|
||||
|
||||
## Changes / New Features
|
||||
|
||||
Major bumps to several important parts of Electron's toolchain, including Chrome `v66.0.3359.181`, Node `v10.2.0`, and V8 `v6.6.346.23.`
|
||||
|
||||
* [[#12656](https://github.com/electron/electron/pull/12656)] feat: `app.isPackaged`
|
||||
* [[#12652](https://github.com/electron/electron/pull/12652)] feat: `app.whenReady()`
|
||||
* [[#13183](https://github.com/electron/electron/pull/13183)] feat: `process.getHeapStatistics()`
|
||||
* [[#12485](https://github.com/electron/electron/pull/12485)] feat: `win.moveTop()` to move window z-order to top
|
||||
* [[#13110](https://github.com/electron/electron/pull/13110)] feat: TextField and Button APIs
|
||||
* [[#13068](https://github.com/electron/electron/pull/13068)] feat: netLog API for dynamic logging control
|
||||
* [[#13539](https://github.com/electron/electron/pull/13539)] feat: enable `webview` in sandbox renderer
|
||||
* [[#14118](https://github.com/electron/electron/pull/14118)] feat: `fs.readSync` now works with massive files
|
||||
* [[#14031](https://github.com/electron/electron/pull/14031)] feat: node `fs` wrappers to make `fs.realpathSync.native` and `fs.realpath.native` available
|
||||
|
||||
## Breaking API changes
|
||||
|
||||
* [[#12362](https://github.com/electron/electron/pull/12362)] feat: updates to menu item order control
|
||||
* [[#13050](https://github.com/electron/electron/pull/13050)] refactor: removed documented deprecated APIs
|
||||
* See [docs](https://github.com/electron/electron/blob/master/docs/api/breaking-changes.md#breaking-api-changes-30) for more details
|
||||
* [[#12477](https://github.com/electron/electron/pull/12477)] refactor: removed `did-get-response-details` and `did-get-redirect-request` events
|
||||
* [[#12655](https://github.com/electron/electron/pull/12655)] feat: default to disabling navigating on drag/drop
|
||||
* [[#12993](https://github.com/electron/electron/pull/12993)] feat: Node `v4.x` or greater is required use the `electron` npm module
|
||||
* [[#12008](https://github.com/electron/electron/pull/12008) [#12140](https://github.com/electron/electron/pull/12140) [#12503](https://github.com/electron/electron/pull/12503) [#12514](https://github.com/electron/electron/pull/12514) [#12584](https://github.com/electron/electron/pull/12584) [#12596](https://github.com/electron/electron/pull/12596) [#12637](https://github.com/electron/electron/pull/12637) [#12660](https://github.com/electron/electron/pull/12660) [#12696](https://github.com/electron/electron/pull/12696) [#12716](https://github.com/electron/electron/pull/12716) [#12750](https://github.com/electron/electron/pull/12750) [#12787](https://github.com/electron/electron/pull/12787) [#12858](https://github.com/electron/electron/pull/12858)] refactor: `NativeWindow`
|
||||
* [[#11968](https://github.com/electron/electron/pull/11968)] refactor: `menu.popup()`
|
||||
* [[#8953](https://github.com/electron/electron/pull/8953)] feat: no longer use JSON to send the result of `ipcRenderer.sendSync`
|
||||
* [[#13039](https://github.com/electron/electron/pull/13039)] feat: default to ignore command line arguments following a URL
|
||||
* [[#12004](https://github.com/electron/electron/pull/12004)] refactor: rename `api::Window` to `api::BrowserWindow`
|
||||
* [[#12679](https://github.com/electron/electron/pull/12679)] feat: visual zoom now turned off by default
|
||||
* [[#12408](https://github.com/electron/electron/pull/12408)] refactor: rename app-command `media-play_pause` to `media-play-pause`
|
||||
|
||||
### macOS
|
||||
|
||||
* [[#12093](https://github.com/electron/electron/pull/12093)] feat: workspace notifications support
|
||||
* [[#12496](https://github.com/electron/electron/pull/12496)] feat: `tray.setIgnoreDoubleClickEvents(ignore)` to ignore tray double click events.
|
||||
* [[#12281](https://github.com/electron/electron/pull/12281)] feat: mouse forward functionality on macOS
|
||||
* [[#12714](https://github.com/electron/electron/pull/12714)] feat: screen lock / unlock events
|
||||
|
||||
### Windows
|
||||
|
||||
* [[#12879](https://github.com/electron/electron/pull/12879)] feat: added DIP to/from screen coordinate conversions
|
||||
|
||||
**Nota Bene:** Switching to an older version of Electron after running this version will require you to clear out your user data directory to avoid older versions crashing. You can get the user data directory by running `console.log(app.getPath("userData"))` or see [docs](https://electronjs.org/docs/api/app#appgetpathname) for more details.
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
* [[#13397](https://github.com/electron/electron/pull/13397)] fix: issue with `fs.statSyncNoException` throwing exceptions
|
||||
* [[#13476](https://github.com/electron/electron/pull/13476), [#13452](https://github.com/electron/electron/pull/13452)] fix: crash when loading site with jquery
|
||||
* [[#14092](https://github.com/electron/electron/pull/14092)] fix: crash in `net::ClientSocketHandle` destructor
|
||||
* [[#14453](https://github.com/electron/electron/pull/14453)] fix: notify focus change right away rather not on next tick
|
||||
|
||||
### MacOS
|
||||
|
||||
* [[#13220](https://github.com/electron/electron/pull/13220)] fix: issue allowing bundles to be selected in `<input file="type">` open file dialog
|
||||
* [[#12404](https://github.com/electron/electron/pull/12404)] fix: issue blocking main process when using async dialog
|
||||
* [[#12043](https://github.com/electron/electron/pull/12043)] fix: context menu click callback
|
||||
* [[#12527](https://github.com/electron/electron/pull/12527)] fix: event leak on reuse of touchbar item
|
||||
* [[#12352](https://github.com/electron/electron/pull/12352)] fix: tray title crash
|
||||
* [[#12327](https://github.com/electron/electron/pull/12327)] fix: non-draggable regions
|
||||
* [[#12809](https://github.com/electron/electron/pull/12809)] fix: to prevent menu update while it's open
|
||||
* [[#13162](https://github.com/electron/electron/pull/13162)] fix: tray icon bounds not allowing negative values
|
||||
* [[#13085](https://github.com/electron/electron/pull/13085)] fix: tray title not inverting when highlighted
|
||||
* [[#12196](https://github.com/electron/electron/pull/12196)] fix: Mac build when `enable_run_as_node==false`
|
||||
* [[#12157](https://github.com/electron/electron/pull/12157)] fix: additional issues on frameless windows with vibrancy
|
||||
* [[#13326](https://github.com/electron/electron/pull/13326)] fix: to set mac protocol to none after calling `app.removeAsDefaultProtocolClient`
|
||||
* [[#13530](https://github.com/electron/electron/pull/13530)] fix: incorrect usage of private APIs in MAS build
|
||||
* [[#13517](https://github.com/electron/electron/pull/13517)] fix: `tray.setContextMenu` crash
|
||||
* [[#14205](https://github.com/electron/electron/pull/14205)] fix: pressing escape on a dialog now closes it even if `defaultId` is set
|
||||
|
||||
### Linux
|
||||
|
||||
* [[#12507](https://github.com/electron/electron/pull/12507)] fix: `BrowserWindow.focus()` for offscreen windows
|
||||
|
||||
## Other Notes
|
||||
|
||||
* PDF Viewer is currently not working but is being worked on and will be functional once again soon
|
||||
* `TextField` and `Button` APIs are experimental and are therefore off by default
|
||||
* They can be enabled with the `enable_view_api` build flag
|
||||
|
||||
# What's Next
|
||||
|
||||
The Electron team continues to work on defining our processes for more rapid and smooth upgrades as we seek to ultimately maintain parity with the development cadences of Chromium, Node, and V8.
|
||||
|
|
@ -1,179 +0,0 @@
|
|||
---
|
||||
title: What's new in Electron 0.37
|
||||
author: zeke
|
||||
date: '2016-03-25'
|
||||
---
|
||||
|
||||
Electron `0.37` was recently [released](https://github.com/electron/electron/releases) and included a major upgrade from Chrome 47 to Chrome 49 and also several new core APIs. This latest release brings in all the new features shipped in [Chrome 48](http://blog.chromium.org/2015/12/chrome-48-beta-present-to-cast-devices_91.html) and [Chrome 49](http://blog.chromium.org/2016/02/chrome-49-beta-css-custom-properties.html). This includes CSS custom properties, increased [ES6](http://www.ecma-international.org/ecma-262/6.0/) support, `KeyboardEvent` improvements, `Promise` improvements, and many other new features now available in your Electron app.
|
||||
|
||||
---
|
||||
|
||||
## What's New
|
||||
|
||||
### CSS Custom Properties
|
||||
|
||||
If you've used preprocessed languages like Sass and Less, you're probably familiar with *variables*, which allow you to define reusable values for things like color schemes and layouts. Variables help keep your stylesheets DRY and more maintainable.
|
||||
|
||||
CSS custom properties are similar to preprocessed variables in that they are reusable, but they also have a unique quality that makes them even more powerful and flexible: **they can be manipulated with JavaScript**. This subtle but powerful feature allows for dynamic changes to visual interfaces while still benefitting from [CSS's hardware acceleration](https://developer.mozilla.org/en-US/Apps/Fundamentals/Performance/Performance_fundamentals#Use_CSS_animations_and_transitions), and reduced code duplication between your frontend code and stylesheets.
|
||||
|
||||
For more info on CSS custom properties, see the [MDN article](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables) and the
|
||||
[Google Chrome demo](https://googlechrome.github.io/samples/css-custom-properties/).
|
||||
|
||||
#### CSS Variables In Action
|
||||
|
||||
Let's walk through a simple variable example that can be tweaked live in your app.
|
||||
|
||||
```css
|
||||
:root {
|
||||
--awesome-color: #A5ECFA;
|
||||
}
|
||||
|
||||
body {
|
||||
background-color: var(--awesome-color);
|
||||
}
|
||||
```
|
||||
|
||||
The variable value can be retrieved and changed directly in JavaScript:
|
||||
|
||||
```js
|
||||
// Get the variable value ' #A5ECFA'
|
||||
let color = window.getComputedStyle(document.body).getPropertyValue('--awesome-color')
|
||||
|
||||
// Set the variable value to 'orange'
|
||||
document.body.style.setProperty('--awesome-color', 'orange')
|
||||
```
|
||||
|
||||
The variable values can be also edited from the **Styles** section of the development tools for quick feedback and tweaks:
|
||||
|
||||
{: .screenshot }
|
||||
|
||||
### `KeyboardEvent.code` Property
|
||||
|
||||
Chrome 48 added the new `code` property available on `KeyboardEvent` events that will be the physical key pressed independent of the operating system keyboard layout.
|
||||
|
||||
This should make implementing custom keyboard shortcuts in your Electron app more accurate and consistent across machines and configurations.
|
||||
|
||||
```js
|
||||
window.addEventListener('keydown', function(event) {
|
||||
console.log(`${event.code} was pressed.`)
|
||||
})
|
||||
```
|
||||
|
||||
Check out [this example](https://googlechrome.github.io/samples/keyboardevent-code-attribute/) to see it in action.
|
||||
|
||||
### Promise Rejection Events
|
||||
|
||||
Chrome 49 added two new `window` events that allow you to be notified when an rejected [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) goes unhandled.
|
||||
|
||||
```js
|
||||
window.addEventListener('unhandledrejection', function (event) {
|
||||
console.log('A rejected promise was unhandled', event.promise, event.reason)
|
||||
})
|
||||
|
||||
window.addEventListener('rejectionhandled', function (event) {
|
||||
console.log('A rejected promise was handled', event.promise, event.reason)
|
||||
})
|
||||
```
|
||||
|
||||
Check out [this example](https://googlechrome.github.io/samples/promise-rejection-events/index.html) to see it in action.
|
||||
|
||||
### ES2015 Updates in V8
|
||||
|
||||
The version of V8 now in Electron incorporates [91% of ES2015](https://kangax.github.io/compat-table/es6/#chrome49). Here are a few interesting additions you can use out of the box—without flags or pre-compilers:
|
||||
|
||||
#### Default parameters
|
||||
|
||||
```js
|
||||
function multiply(x, y = 1) {
|
||||
return x * y
|
||||
}
|
||||
|
||||
multiply(5) // 5
|
||||
```
|
||||
|
||||
#### Destructuring assignment
|
||||
|
||||
Chrome 49 added [destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) to make assigning variables and function parameters much easier.
|
||||
|
||||
This makes Electron requires cleaner and more compact to assign now:
|
||||
|
||||
##### Browser Process Requires
|
||||
|
||||
```js
|
||||
const {app, BrowserWindow, Menu} = require('electron')
|
||||
```
|
||||
|
||||
##### Renderer Process Requires
|
||||
|
||||
```js
|
||||
const {dialog, Tray} = require('electron').remote
|
||||
```
|
||||
|
||||
##### Other Examples
|
||||
|
||||
```js
|
||||
// Destructuring an array and skipping the second element
|
||||
const [first, , last] = findAll()
|
||||
|
||||
// Destructuring function parameters
|
||||
function whois({displayName: displayName, fullName: {firstName: name}}){
|
||||
console.log(`${displayName} is ${name}`)
|
||||
}
|
||||
|
||||
let user = {
|
||||
displayName: "jdoe",
|
||||
fullName: {
|
||||
firstName: "John",
|
||||
lastName: "Doe"
|
||||
}
|
||||
}
|
||||
whois(user) // "jdoe is John"
|
||||
|
||||
// Destructuring an object
|
||||
let {name, avatar} = getUser()
|
||||
```
|
||||
|
||||
## New Electron APIs
|
||||
|
||||
A few of the new Electron APIs are below, you can see each new API in the release notes for [Electron releases](https://github.com/electron/electron/releases).
|
||||
|
||||
#### `show` and `hide` events on `BrowserWindow`
|
||||
|
||||
These events are emitted when the window is either shown or hidden.
|
||||
|
||||
```js
|
||||
const {BrowserWindow} = require('electron')
|
||||
|
||||
let window = new BrowserWindow({width: 500, height: 500})
|
||||
window.on('show', function () { console.log('Window was shown') })
|
||||
window.on('hide', function () { console.log('Window was hidden') })
|
||||
```
|
||||
|
||||
#### `platform-theme-changed` on `app` for `OS X`
|
||||
|
||||
This event is emitted when the system’s [Dark Mode](https://discussions.apple.com/thread/6661740) theme is toggled.
|
||||
|
||||
```js
|
||||
const {app} = require('electron')
|
||||
|
||||
app.on('platform-theme-changed', function () {
|
||||
console.log(`Platform theme changed. In dark mode? ${app.isDarkMode()}`)
|
||||
})
|
||||
```
|
||||
|
||||
#### `app.isDarkMode()` for `OS X`
|
||||
|
||||
This method returns `true` if the system is in Dark Mode, and `false` otherwise.
|
||||
|
||||
#### `scroll-touch-begin` and `scroll-touch-end` events to BrowserWindow for `OS X`
|
||||
|
||||
These events are emitted when the scroll wheel event phase has begun or has ended.
|
||||
|
||||
```js
|
||||
const {BrowserWindow} = require('electron')
|
||||
|
||||
let window = new BrowserWindow({width: 500, height: 500})
|
||||
window.on('scroll-touch-begin', function () { console.log('Scroll touch started') })
|
||||
window.on('scroll-touch-end', function () { console.log('Scroll touch ended') })
|
||||
```
|
||||
|
||||
|
|
@ -1,145 +0,0 @@
|
|||
---
|
||||
title: Electron 4.0.0
|
||||
author: BinaryMuse
|
||||
date: '2018-12-20'
|
||||
---
|
||||
|
||||
The Electron team is excited to announce that the stable release of Electron 4 is now available! You can install it from [electronjs.org](https://electronjs.org/) or from npm via `npm install electron@latest`. The release is packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Read more for details about this release, and please share any feedback you have as you explore!
|
||||
|
||||
---
|
||||
|
||||
## What's New?
|
||||
|
||||
A large part of Electron's functionality is provided by Chromium, Node.js, and V8, the core components that make up Electron. As such, a key goal for the Electron team is to keep up with changes to these projects as much as possible, providing developers who build Electron apps access to new web and JavaScript features. To this end, Electron 4 features major version bumps to each of these components; Electron v4.0.0 includes Chromium `69.0.3497.106`, Node `10.11.0`, and V8 `6.9.427.24`.
|
||||
|
||||
In addition, Electron 4 includes changes to Electron-specific APIs. You can find a summary of the major changes in Electron 4 below; for the full list of changes, check out the [Electron v4.0.0 release notes](https://github.com/electron/electron/releases/tag/v4.0.0).
|
||||
|
||||
### Disabling the `remote` Module
|
||||
|
||||
You now have the ability to disable the `remote` module for security reasons. The module can be disabled for `BrowserWindow`s and for `webview` tags:
|
||||
|
||||
```javascript
|
||||
// BrowserWindow
|
||||
new BrowserWindow({
|
||||
webPreferences: {
|
||||
enableRemoteModule: false
|
||||
}
|
||||
})
|
||||
|
||||
// webview tag
|
||||
<webview src="http://www.google.com/" enableremotemodule="false"></webview>
|
||||
```
|
||||
|
||||
See the [BrowserWindow](https://electronjs.org/docs/api/browser-window) and [`<webview>` Tag](https://electronjs.org/docs/api/webview-tag) documentation for more information.
|
||||
|
||||
### Filtering `remote.require()` / `remote.getGlobal()` Requests
|
||||
|
||||
This feature is useful if you don't want to completely disable the `remote` module in your renderer process or `webview` but would like additional control over which modules can be required via `remote.require`.
|
||||
|
||||
When a module is required via `remote.require` in a renderer process, a `remote-require` event is raised on the [`app` module](https://electronjs.org/docs/api/app). You can call `event.preventDefault()` on the the event (the first argument) to prevent the module from being loaded. The [`WebContents` instance](https://electronjs.org/docs/api/web-contents) where the require occurred is passed as the second argument, and the name of the module is passed as the third argument. The same event is also emitted on the `WebContents` instance, but in this case the only arguments are the event and the module name. In both cases, you can return a custom value by setting the value of `event.returnValue`.
|
||||
|
||||
```javascript
|
||||
// Control `remote.require` from all WebContents:
|
||||
app.on('remote-require', function (event, webContents, requestedModuleName) {
|
||||
// ...
|
||||
})
|
||||
|
||||
// Control `remote.require` from a specific WebContents instance:
|
||||
browserWin.webContents.on('remote-require', function (event, requestedModuleName) {
|
||||
// ...
|
||||
})
|
||||
```
|
||||
|
||||
In a similar fashion, when `remote.getGlobal(name)` is called, a `remote-get-global` event is raised. This works the same way as the `remote-require` event: call `preventDefault()` to prevent the global from being returned, and set `event.returnValue` to return a custom value.
|
||||
|
||||
```javascript
|
||||
// Control `remote.getGlobal` from all WebContents:
|
||||
app.on('remote-get-global', function (event, webContents, requrestedGlobalName) {
|
||||
// ...
|
||||
})
|
||||
|
||||
// Control `remote.getGlobal` from a specific WebContents instance:
|
||||
browserWin.webContents.on('remote-get-global', function (event, requestedGlobalName) {
|
||||
// ...
|
||||
})
|
||||
```
|
||||
|
||||
For more information, see the following documentation:
|
||||
|
||||
* [`remote.require`](https://electronjs.org/docs/api/remote#remoterequiremodule)
|
||||
* [`remote.getGlobal`](https://electronjs.org/docs/api/remote#remotegetglobalname)
|
||||
* [`app`](https://electronjs.org/docs/api/app)
|
||||
* [`WebContents`](https://electronjs.org/docs/api/web-contents)
|
||||
|
||||
### JavaScript Access to the About Panel
|
||||
|
||||
On macOS, you can now call `app.showAboutPanel()` to programmatically show the About panel, just like clicking the menu item created via `{role: 'about'}`. See the [`showAboutPanel` documentation](https://electronjs.org/docs/api/app?query=show#appshowaboutpanel-macos) for more information
|
||||
|
||||
### Controlling `WebContents` Background Throttling
|
||||
|
||||
`WebContents` instances now have a method `setBackgroundThrottling(allowed)` to enable or disable throttling of timers and animations when the page is backgrounded.
|
||||
|
||||
```javascript
|
||||
let win = new BrowserWindow(...)
|
||||
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)
|
||||
```
|
||||
|
||||
See [the `setBackgroundThrottling` documentation](https://electronjs.org/docs/api/web-contents#contentssetbackgroundthrottlingallowed) for more information.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
### No More macOS 10.9 Support
|
||||
|
||||
Chromium no longer supports macOS 10.9 (OS X Mavericks), and as a result [Electron 4.0 and beyond does not support it either](https://github.com/electron/electron/pull/15357).
|
||||
|
||||
### Single Instance Locking
|
||||
|
||||
Previously, to make your app a Single Instance Application (ensuring that only one instance of your app is running at any given time), you could use the `app.makeSingleInstance()` method. Starting in Electron 4.0, you must use `app.requestSingleInstanceLock()` instead. The return value of this method indicates whether or not this instance of your application successfully obtained the lock. If it failed to obtain the lock, you can assume that another instance of your application is already running with the lock and exit immediately.
|
||||
|
||||
For an example of using `requestSingleInstanceLock()` and information on nuanced behavior on various platforms, [see the documentation for `app.requestSingleInstanceLock()` and related methods](https://electronjs.org/docs/api/app#apprequestsingleinstancelock) and [the `second-instance` event](https://electronjs.org/docs/api/app#event-second-instance).
|
||||
|
||||
### `win_delay_load_hook`
|
||||
|
||||
When building native modules for windows, the `win_delay_load_hook` variable in the module's `binding.gyp` must be true (which is the default). If this hook is not present, then the native module will fail to load on Windows, with an error message like `Cannot find module`. [See the native module guide](https://electronjs.org/docs/tutorial/using-native-node-modules#a-note-about-win_delay_load_hook) for more information.
|
||||
|
||||
## Deprecations
|
||||
|
||||
The following breaking changes are planned for Electron 5.0, and thus are deprecated in Electron 4.0.
|
||||
|
||||
### Node.js Integration Disabled for `nativeWindowOpen`-ed Windows
|
||||
|
||||
Starting in Electron 5.0, child windows opened with the `nativeWindowOpen` option will always have Node.js integration disabled.
|
||||
|
||||
### `webPreferences` Default Values
|
||||
|
||||
When creating a new `BrowserWindow` with the `webPreferences` option set, the following `webPreferences` option defaults are deprecated in favor of new defaults listed below:
|
||||
|
||||
<div class="table table-ruled table-full-width">
|
||||
|
||||
| Property | Deprecated Default | New Default |
|
||||
|----------|--------------------|-------------|
|
||||
| `contextIsolation` | `false` | `true` |
|
||||
| `nodeIntegration` | `true` | `false` |
|
||||
| `webviewTag` | value of `nodeIntegration` if set, otherwise `true` | `false` |
|
||||
|
||||
</div>
|
||||
|
||||
Please note: there is currently [a known bug (#9736)](https://github.com/electron/electron/issues/9736) that prevents the `webview` tag from working if `contextIsolation` is on. Keep an eye on the GitHub issue for up-to-date information!
|
||||
|
||||
Learn more about context isolation, Node integration, and the `webview` tag in [the Electron security document](https://electronjs.org/docs/tutorial/security).
|
||||
|
||||
Electron 4.0 will still use the current defaults, but if you don't pass an explicit value for them, you'll see a deprecation warning. To prepare your app for Electron 5.0, use explicit values for these options. [See the `BrowserWindow` docs](https://electronjs.org/docs/api/browser-window#new-browserwindowoptions) for details on each of these options.
|
||||
|
||||
### `webContents.findInPage(text[, options])`
|
||||
|
||||
The `medialCapitalAsWordStart` and `wordStart` options have been deprecated as they have been removed upstream.
|
||||
|
||||
## App Feedback Program
|
||||
|
||||
The [App Feedback Program](https://electronjs.org/blog/app-feedback-program) we instituted during the development of Electron 3.0 was successful, so we've continued it during the development of 4.0 as well. We'd like to extend a massive thank you to Atlassian, Discord, MS Teams, OpenFin, Slack, Symphony, WhatsApp, and the other program members for their involvement during the 4.0 beta cycle. To learn more about the App Feedback Program and to participate in future betas, [check out our blog post about the program](https://electronjs.org/blog/app-feedback-program).
|
||||
|
||||
## What's Next
|
||||
|
||||
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. [See our versioning document](https://electronjs.org/docs/tutorial/electron-versioning) for more detailed information about versioning in Electron.
|
||||
|
||||
For information on planned breaking changes in upcoming versions of Electron, [see our Planned Breaking Changes doc](https://github.com/electron/electron/blob/master/docs/api/breaking-changes.md).
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
---
|
||||
title: Electron v5.0.0 Timeline
|
||||
author: sofianguy
|
||||
date: '2019-01-25'
|
||||
---
|
||||
|
||||
For the first time ever, Electron is excited to publicize our release schedule starting with v5.0.0. This is our first step in having a public, long-term timeline.
|
||||
|
||||
---
|
||||
|
||||
As mentioned in our v4.0.0 stable release [blog post](https://electronjs.org/blog/electron-4-0#whats-next), we are planning to release approximately quarterly to maintain closer cadence with Chromium releases. Chromium releases a new version very quickly -- every 6 weeks.
|
||||
|
||||
Take a look at progression in Electron versus Chromium side-by-side:
|
||||
<img src="https://user-images.githubusercontent.com/2138661/51714676-db167080-1fea-11e9-8f10-fab1aa51993e.png" alt="line graph comparing Electron versus Chromium versions"/>
|
||||
|
||||
In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.
|
||||
|
||||
We would love to promise future dates like [Node.js](https://github.com/nodejs/Release) and [Chromium](https://chromiumdash.appspot.com/schedule) do, but we are not at that place _yet_. We are optimistic that we will reach a long-term timeline in the future.
|
||||
|
||||
With that in mind, we are taking first steps by publicly posting our release schedule for v5.0.0. You can find that [here](https://electronjs.org/docs/tutorial/electron-timelines).
|
||||
|
||||
To help us with testing our beta releases and stabilization, please consider joining our [App Feedback Program](https://electronjs.org/blog/app-feedback-program).
|
||||
|
|
@ -1,120 +0,0 @@
|
|||
---
|
||||
title: Electron 5.0.0
|
||||
author:
|
||||
- BinaryMuse
|
||||
- ckerr
|
||||
- jkleinsc
|
||||
date: '2019-04-23'
|
||||
---
|
||||
|
||||
The Electron team is excited to announce the release of Electron 5.0.0! You can install it with npm via `npm install electron@latest` or download the tarballs from [our releases page](https://github.com/electron/electron/releases/tag/v5.0.0). The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
|
||||
|
||||
---
|
||||
|
||||
## What's New?
|
||||
|
||||
Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 5:
|
||||
|
||||
- Chromium `73.0.3683.119`
|
||||
- [New in 70](https://developers.google.com/web/updates/2018/10/nic70)
|
||||
- [New in 71](https://developers.google.com/web/updates/2018/12/nic71)
|
||||
- [New in 72](https://developers.google.com/web/updates/2019/01/nic72)
|
||||
- [New in 73](https://developers.google.com/web/updates/2019/03/nic73)
|
||||
- Node.js `12.0.0`
|
||||
- [Node 12 Blog Post](https://nodejs.org/en/blog/release/v12.0.0/)
|
||||
- V8 `7.3.492.27`.
|
||||
- [New JS Features](https://twitter.com/mathias/status/1120700101637353473)
|
||||
|
||||
Electron 5 also includes improvements to Electron-specific APIs. A summary of the major changes is below; for the full list of changes, check out the [Electron v5.0.0 release notes](https://github.com/electron/electron/releases/tag/v5.0.0).
|
||||
|
||||
### Promisification
|
||||
|
||||
Electron 5 continues [Promisification initiative](https://github.com/electron/electron/blob/5-0-x/docs/api/promisification.md) initiative to convert Electron's callback-based API to use Promises. These APIs were converted for Electron 5:
|
||||
* `app.getFileIcon`
|
||||
* `contentTracing.getCategories`
|
||||
* `contentTracing.startRecording`
|
||||
* `contentTracing.stopRecording`
|
||||
* `debugger.sendCommand`
|
||||
* Cookies API
|
||||
* `shell.openExternal`
|
||||
* `webContents.loadFile`
|
||||
* `webContents.loadURL`
|
||||
* `webContents.zoomLevel`
|
||||
* `webContents.zoomFactor`
|
||||
* `win.capturePage`
|
||||
|
||||
### System colors access for macOS
|
||||
|
||||
These functions were changed or added to `systemPreferences` to access macOS systems' colors:
|
||||
* `systemPreferences.getAccentColor`
|
||||
* `systemPreferences.getColor`
|
||||
* `systemPreferences.getSystemColor`
|
||||
|
||||
### Process memory information
|
||||
|
||||
The function `process.getProcessMemoryInfo` has been added to get memory usage statistics about the current process.
|
||||
|
||||
### Additional filtering for remote APIs
|
||||
|
||||
To improve security in the `remote` API, new remote events have been added so that `remote.getBuiltin`, `remote.getCurrentWindow`, `remote.getCurrentWebContents` and `<webview>.getWebContents` can be [filtered](https://github.com/electron/electron/blob/master/docs/tutorial/security.md#13-disable-or-limit-creation-of-new-windows).
|
||||
|
||||
### Multiple BrowserViews on BrowserWindow
|
||||
|
||||
BrowserWindow now supports managing multiple BrowserViews within the same BrowserWindow.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
### Defaults for packaged apps
|
||||
|
||||
Packaged apps will now behave the same as the default app: a default application menu will be created unless the app has one and the `window-all-closed` event will be automatically handled unless the app handles the event.
|
||||
|
||||
### Mixed sandbox
|
||||
|
||||
Mixed sandbox mode is now enabled by default. Renderers launched with `sandbox: true` will now be actually sandboxed, where previously they would only be sandboxed if mixed-sandbox mode was also enabled.
|
||||
|
||||
### Security improvements
|
||||
The default values of `nodeIntegration` and `webviewTag` are now `false` to improve security.
|
||||
|
||||
### Spellchecker now asynchronous
|
||||
|
||||
The SpellCheck API has been changed to provide [asynchronous results](https://github.com/electron/electron/blob/5-0-x/docs/api/web-frame.md#webframesetspellcheckproviderlanguage-provider).
|
||||
|
||||
## Deprecations
|
||||
|
||||
The following APIs are newly deprecated in Electron 5.0.0 and planned for removal in 6.0.0:
|
||||
|
||||
### Mksnapshot binaries for arm and arm64
|
||||
Native binaries of mksnapshot for arm and arm64 are deprecated and will be removed in 6.0.0. Snapshots can be created for arm and arm64 using the x64 binaries.
|
||||
|
||||
### ServiceWorker APIs on WebContents
|
||||
Deprecated ServiceWorker APIs on WebContents in preparation for their removal.
|
||||
* `webContents.hasServiceWorker`
|
||||
* `webContents.unregisterServiceWorker`
|
||||
|
||||
### Automatic modules with sandboxed webContents
|
||||
In order to improve security, the following modules are being deprecated for use directly via `require` and will instead need to be included via `remote.require` in a sandboxed webcontents:
|
||||
* `electron.screen`
|
||||
* `child_process`
|
||||
* `fs`
|
||||
* `os`
|
||||
* `path`
|
||||
|
||||
## webFrame Isolated World APIs
|
||||
`webFrame.setIsolatedWorldContentSecurityPolicy`,`webFrame.setIsolatedWorldHumanReadableName`, `webFrame.setIsolatedWorldSecurityOrigin` have been deprecated in favor of `webFrame.setIsolatedWorldInfo`.
|
||||
|
||||
### Mixed sandbox
|
||||
`enableMixedSandbox` and the `--enable-mixed-sandbox` command-line switch still exist for compatibility, but are deprecated and have no effect.
|
||||
|
||||
## End of support for 2.0.x
|
||||
|
||||
Per our [supported versions policy](https://electronjs.org/docs/tutorial/support#supported-versions), 2.0.x has reached end of life.
|
||||
|
||||
## App Feedback Program
|
||||
|
||||
We continue to use our [App Feedback Program](https://electronjs.org/blog/app-feedback-program) for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, [check out our blog post about the program](https://electronjs.org/blog/app-feedback-program).
|
||||
|
||||
## What's Next
|
||||
|
||||
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The [tentative 6.0.0 schedule](https://electronjs.org/docs/tutorial/electron-timelines#600-release-schedule) maps out key dates in the Electron 6 development life cycle. Also, [see our versioning document](https://electronjs.org/docs/tutorial/electron-versioning) for more detailed information about versioning in Electron.
|
||||
|
||||
For information on planned breaking changes in upcoming versions of Electron, [see our Planned Breaking Changes doc](https://github.com/electron/electron/blob/master/docs/api/breaking-changes.md).
|
||||
|
|
@ -1,108 +0,0 @@
|
|||
---
|
||||
title: Electron 6.0.0
|
||||
author:
|
||||
- sofianguy
|
||||
- ckerr
|
||||
- codebytere
|
||||
date: '2019-07-30'
|
||||
---
|
||||
|
||||
The Electron team is excited to announce the release of Electron 6.0.0! You can install it with npm via `npm install electron@latest` or download it from our [releases website](https://electronjs.org/releases/stable). The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
|
||||
|
||||
---
|
||||
|
||||
## What's New
|
||||
|
||||
Today marks a first for the Electron project: this is the first time we've made a stable Electron release **on the same day** as the corresponding [Chrome stable release](https://www.chromestatus.com/features/schedule)! 🎉
|
||||
|
||||
Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 6:
|
||||
|
||||
- Chromium `76.0.3809.88`
|
||||
- [New in 74](https://developers.google.com/web/updates/2019/04/nic74)
|
||||
- [New in 75](https://developers.google.com/web/updates/2019/06/nic75)
|
||||
- [New in 76](https://developers.google.com/web/updates/2019/07/nic76)
|
||||
- Node.js `12.4.0`
|
||||
- [Node 12.4.0 blog post](https://nodejs.org/en/blog/release/v12.4.0/)
|
||||
- V8 `7.6.303.22`
|
||||
- [V8 7.6 blog post](https://v8.dev/blog/v8-release-76)
|
||||
|
||||
This release also includes improvements to Electron's APIs. [The release notes](https://github.com/electron/electron/releases/tag/v6.0.0) have a more complete list, but here are the highlights:
|
||||
|
||||
### Promisification
|
||||
|
||||
Electron 6.0 continues the modernization [initiative](https://github.com/electron/electron/blob/master/docs/api/modernization/promisification.md) started in 5.0 to improve [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises) support.
|
||||
|
||||
These functions now return Promises and still support older callback-based invocation:
|
||||
* `contentTracing.getCategories()` [#16583](https://github.com/electron/electron/pull/16583)
|
||||
* `contentTracing.getCategories()` [#16583](https://github.com/electron/electron/pull/16583)
|
||||
* `contentTracing.getTraceBufferUsage()` [#16600](https://github.com/electron/electron/pull/16600)
|
||||
* `contents.executeJavaScript()` [#17312](https://github.com/electron/electron/pull/17312)
|
||||
* `cookies.flushStore()` [#16464](https://github.com/electron/electron/pull/16464)
|
||||
* `cookies.get()` [#16464](https://github.com/electron/electron/pull/16464)
|
||||
* `cookies.remove()` [#16464](https://github.com/electron/electron/pull/16464)
|
||||
* `cookies.set()` [#16464](https://github.com/electron/electron/pull/16464)
|
||||
* `dialog.showCertificateTrustDialog()` [#17181](https://github.com/electron/electron/pull/17181)
|
||||
* `inAppPurchase.getProducts()` [#17355](https://github.com/electron/electron/pull/17355)
|
||||
* `inAppPurchase.purchaseProduct()`[#17355](https://github.com/electron/electron/pull/17355)
|
||||
* `netLog.stopLogging()` [#16862](https://github.com/electron/electron/pull/16862)
|
||||
* `session.clearAuthCache()` [#17259](https://github.com/electron/electron/pull/17259)
|
||||
* `session.clearCache()` [#17185](https://github.com/electron/electron/pull/17185)
|
||||
* `session.clearHostResolverCache()` [#17229](https://github.com/electron/electron/pull/17229)
|
||||
* `session.clearStorageData()` [#17249](https://github.com/electron/electron/pull/17249)
|
||||
* `session.getBlobData()` [#17303](https://github.com/electron/electron/pull/17303)
|
||||
* `session.getCacheSize()` [#17185](https://github.com/electron/electron/pull/17185)
|
||||
* `session.resolveProxy()` [#17222](https://github.com/electron/electron/pull/17222)
|
||||
* `session.setProxy()` [#17222](https://github.com/electron/electron/pull/17222)
|
||||
* `webContents.hasServiceWorker()` [#16535](https://github.com/electron/electron/pull/16535)
|
||||
* `webContents.printToPDF()` [#16795](https://github.com/electron/electron/pull/16795)
|
||||
* `webContents.savePage()` [#16742](https://github.com/electron/electron/pull/16742)
|
||||
* `webFrame.executeJavaScript()` [#17312](https://github.com/electron/electron/pull/17312)
|
||||
* `webFrame.executeJavaScriptInIsolatedWorld()` [#17312](https://github.com/electron/electron/pull/17312)
|
||||
* `webviewTag.executeJavaScript()` [#17312](https://github.com/electron/electron/pull/17312)
|
||||
|
||||
These functions now have two forms, synchronous and Promise-based asynchronous:
|
||||
* `dialog.showMessageBox()`/`dialog.showMessageBoxSync()` [#17298](https://github.com/electron/electron/pull/17298)
|
||||
* `dialog.showOpenDialog()`/`dialog.showOpenDialogSync()` [#16973](https://github.com/electron/electron/pull/16973)
|
||||
* `dialog.showSaveDialog()`/`dialog.showSaveDialogSync()` [#17054](https://github.com/electron/electron/pull/17054)
|
||||
|
||||
These functions now return Promises:
|
||||
* `app.dock.show()` [#16904](https://github.com/electron/electron/pull/16904)
|
||||
|
||||
### `Electron Helper (Renderer).app`, `Electron Helper (GPU).app` and `Electron Helper (Plugin).app`
|
||||
|
||||
In order to enable the [hardened runtime](https://developer.apple.com/documentation/security/hardened_runtime_entitlements?language=objc), which restricts things like
|
||||
writable-executable memory and loading code signed by a different Team
|
||||
ID, special code signing entitlements needed to be granted to the Helper.
|
||||
|
||||
To keep these entitlements scoped to the process types that require them, Chromium [added](https://chromium-review.googlesource.com/c/chromium/src/+/1627456)
|
||||
three new variants of the Helper app: one for renderers (`Electron Helper (Renderer).app`), one for the GPU process (`Electron Helper (GPU).app`) and one for plugins (`Electron Helper (Plugin).app`).
|
||||
|
||||
Folks using `electron-osx-sign` to codesign their Electron app shouldn't have to make any changes to their build logic.
|
||||
If you're codesigning your app with custom scripts, you should ensure
|
||||
that the three new Helper applications are correctly codesigned.
|
||||
|
||||
In order to package your application correctly with these new helpers you need to be using `electron-packager@14.0.4` or higher. If you are using `electron-builder` you should follow [this issue](https://github.com/electron-userland/electron-builder/issues/4104) to track support for these new helpers.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
* This release begins laying the groundwork for a future requirement that native Node modules loaded in the renderer process be either [N-API](https://nodejs.org/api/n-api.html) or [Context Aware](https://nodejs.org/api/addons.html#addons_context_aware_addons). The reasons for this change are faster performance, stronger security, and reduced maintenance workload. Read the full details including the proposed timeline in [this issue](https://github.com/electron/electron/issues/18397). This change is expected to be completed in Electron v11.
|
||||
|
||||
* `net.IncomingMessage` headers have [changed slightly](https://github.com/electron/electron/pull/17517#issue-263752903) to more closely match [Node.js behavior](https://nodejs.org/api/http.html#http_message_headers), particularly with the value of `set-cookie` and how duplicate headers are handled. [#17517](https://github.com/electron/electron/pull/17517).
|
||||
|
||||
* `shell.showItemInFolder()` now returns void and is an asynchronous call. [#17121](https://github.com/electron/electron/pull/17121)
|
||||
|
||||
* Apps must now explicitly set a log path by calling the new function `app.setAppLogPath()` before using `app.getPath('log')`. [#17841](https://github.com/electron/electron/pull/17841)
|
||||
|
||||
## End of Support for 3.x.y
|
||||
|
||||
Per our [support policy](https://electronjs.org/docs/tutorial/support#supported-versions), 3.x.y has reached end of life. Developers and applications are encouraged to upgrade to a newer version of Electron.
|
||||
|
||||
## App Feedback Program
|
||||
|
||||
We continue to use our [App Feedback Program](https://electronjs.org/blog/app-feedback-program) for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, [check out our blog post about the program](https://electronjs.org/blog/app-feedback-program).
|
||||
|
||||
## What's Next
|
||||
|
||||
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The [tentative 7.0.0 schedule](https://electronjs.org/docs/tutorial/electron-timelines) maps out key dates in the Electron 7 development life cycle. Also, [see our versioning document](https://electronjs.org/docs/tutorial/electron-versioning) for more detailed information about versioning in Electron.
|
||||
|
||||
For information on planned breaking changes in upcoming versions of Electron, [see our Planned Breaking Changes doc](https://github.com/electron/electron/blob/master/docs/api/breaking-changes.md).
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
---
|
||||
title: Electron 7.0.0
|
||||
author:
|
||||
- sofianguy
|
||||
- ckerr
|
||||
date: '2019-10-22'
|
||||
---
|
||||
|
||||
Electron 7.0.0 has been released! It includes upgrades to Chromium 78, V8 7.8, and Node.js 12.8.1. We've added a Window on Arm 64 release, faster IPC methods, a new `nativeTheme` API, and much more!
|
||||
|
||||
---
|
||||
|
||||
The Electron team is excited to announce the release of Electron 7.0.0! You can install it with npm via `npm install electron@latest` or download it from our [releases website](https://electronjs.org/releases/stable). The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
|
||||
|
||||
## Notable Changes
|
||||
* Stack Upgrades:
|
||||
|
||||
| Stack | Version in Electron 6 | Version in Electron 7 | What's New |
|
||||
|:---------|:----------------------|:----------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Chromium | 76.0.3809.146 | **78.0.3905.1** | [77](https://developers.google.com/web/updates/2019/09/nic77), [78](https://developers.google.com/web/updates/2019/10/nic78)
|
||||
| V8 | 7.6 | **7.8** | [7.7](https://v8.dev/blog/v8-release-77), [7.8](https://v8.dev/blog/v8-release-78)
|
||||
| Node.js | 12.4.0 | **12.8.1** | [12.5](https://nodejs.org/en/blog/release/v12.5.0/), [12.6](https://nodejs.org/en/blog/release/v12.6.0/), [12.7](https://nodejs.org/en/blog/release/v12.7.0/), [12.8](https://nodejs.org/en/blog/release/v12.8.0/), [12.8.1](https://nodejs.org/en/blog/release/v12.8.1/)
|
||||
* Added Windows on Arm (64 bit) release. [#18591](https://github.com/electron/electron/pull/18591), [#20112](https://github.com/electron/electron/pull/20112)
|
||||
* Added `ipcRenderer.invoke()` and `ipcMain.handle()` for asynchronous request/response-style IPC. These are strongly recommended over the `remote` module. See this "[Electron’s ‘remote’ module considered harmful](https://medium.com/@nornagon/electrons-remote-module-considered-harmful-70d69500f31)" blog post for more information. [#18449](https://github.com/electron/electron/pull/18449)
|
||||
* Added `nativeTheme` API to read and respond to changes in the OS's theme and color scheme. [#19758](https://github.com/electron/electron/pull/19758), [#20486](https://github.com/electron/electron/pull/20486)
|
||||
* Switched to a new TypeScript Definitions [generator](https://github.com/electron/docs-parser). The resulting definitions are more precise; so if your TypeScript build fails, this is the likely cause. [#18103](https://github.com/electron/electron/pull/18103)
|
||||
|
||||
See the [7.0.0 release notes](https://github.com/electron/electron/releases/tag/v7.0.0) for a longer list of changes.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
More information about these and future changes can be found on the [Planned Breaking Changes](https://github.com/electron/electron/blob/master/docs/api/breaking-changes.md) page.
|
||||
|
||||
* Removed deprecated APIs:
|
||||
* Callback-based versions of functions that now use Promises. [#17907](https://github.com/electron/electron/pull/17907)
|
||||
* `Tray.setHighlightMode()` (macOS). [#18981](https://github.com/electron/electron/pull/18981)
|
||||
* `app.enableMixedSandbox()` [#17894](https://github.com/electron/electron/pull/17894)
|
||||
* `app.getApplicationMenu()`,
|
||||
* `app.setApplicationMenu()`,
|
||||
* `powerMonitor.querySystemIdleState()`,
|
||||
* `powerMonitor.querySystemIdleTime()`,
|
||||
* `webFrame.setIsolatedWorldContentSecurityPolicy()`,
|
||||
* `webFrame.setIsolatedWorldHumanReadableName()`,
|
||||
* `webFrame.setIsolatedWorldSecurityOrigin()` [#18159](https://github.com/electron/electron/pull/18159)
|
||||
* `Session.clearAuthCache()` no longer allows filtering the cleared cache entries. [#17970](https://github.com/electron/electron/pull/17970)
|
||||
* Native interfaces on macOS (menus, dialogs, etc.) now automatically match the dark mode setting on the user's machine. [#19226](https://github.com/electron/electron/pull/19226)
|
||||
* Updated the `electron` module to use `@electron/get`. The minimum supported node version is now Node 8. [#18413](https://github.com/electron/electron/pull/18413)
|
||||
* The file `electron.asar` no longer exists. Any packaging scripts that depend on its existence should be updated. [#18577](https://github.com/electron/electron/pull/18577)
|
||||
|
||||
## End of Support for 4.x.y
|
||||
|
||||
Electron 4.x.y has reached end-of-support as per the project's
|
||||
[support policy](https://electronjs.org/docs/tutorial/support#supported-versions).
|
||||
Developers and applications are encouraged to upgrade to a newer version of Electron.
|
||||
|
||||
## App Feedback Program
|
||||
|
||||
We continue to use our [App Feedback Program](https://electronjs.org/blog/app-feedback-program)
|
||||
for testing. Projects who participate in this program test Electron betas
|
||||
on their apps; and in return, the new bugs they find are prioritized for
|
||||
the stable release. If you'd like to participate or learn more,
|
||||
[check out our blog post about the program](https://electronjs.org/blog/app-feedback-program).
|
||||
|
||||
## What's Next
|
||||
|
||||
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The [tentative 8.0.0 schedule](https://electronjs.org/docs/tutorial/electron-timelines) maps out key dates in the Electron 8 development life cycle. Also, [see our versioning document](https://electronjs.org/docs/tutorial/electron-versioning) for more detailed information about versioning in Electron.
|
||||
|
||||
For information on planned breaking changes in upcoming versions of Electron, [see our Planned Breaking Changes doc](https://github.com/electron/electron/blob/master/docs/api/breaking-changes.md).
|
||||
|
|
@ -1,110 +0,0 @@
|
|||
---
|
||||
title: Electron 8.0.0
|
||||
author:
|
||||
- jkleinsc
|
||||
- sofianguy
|
||||
date: '2020-02-04'
|
||||
---
|
||||
|
||||
Electron 8.0.0 has been released! It includes upgrades to Chromium `80`, V8 `8.0`, and Node.js `12.13.0`. We've added Chrome's built-in spellchecker, and much more!
|
||||
|
||||
---
|
||||
|
||||
The Electron team is excited to announce the release of Electron 8.0.0! You can install it with npm via `npm install electron@latest` or download it from our [releases website](https://electronjs.org/releases/stable). The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
|
||||
|
||||
## Notable Changes
|
||||
|
||||
### Stack Changes
|
||||
* Chromium `80.0.3987.86`
|
||||
* [New in Chrome 79](https://developers.google.com/web/updates/2019/12/nic79)
|
||||
* [New in Chrome 80](https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html)
|
||||
* Node.js `12.13.0`
|
||||
* [Node 12.13.0 blog post](https://nodejs.org/en/blog/release/v12.13.0/)
|
||||
* V8 `8.0`
|
||||
* [V8 7.9 blog post](https://v8.dev/blog/v8-release-79)
|
||||
* [V8 8.0 blog post](https://v8.dev/blog/v8-release-80)
|
||||
|
||||
### Highlight Features
|
||||
* Implemented usage of Chrome's built-in spellchecker feature. See more details in [#20692](https://github.com/electron/electron/pull/20692) and [#21266](https://github.com/electron/electron/pull/21266).
|
||||
* IPC communication now uses v8's Structured Clone Algorithm. This is faster, more featureful, and less surprising than the existing logic, and brings about a 2x performance boost for large buffers and complex objects. Latency for small messages is not significantly affected. See more details in [#20214](https://github.com/electron/electron/pull/20214).
|
||||
|
||||
See the [8.0.0 release notes](https://github.com/electron/electron/releases/tag/v8.0.0) for a full list of new features and changes.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
* Show module name in deprecation warning for context-aware modules. [#21952](https://github.com/electron/electron/pull/21952)
|
||||
* This is continued work for a future requirement that native Node modules loaded in the renderer process be either [N-API](https://nodejs.org/api/n-api.html) or [Context Aware](https://nodejs.org/api/addons.html#addons_context_aware_addons). Full info and proposed timeline is detailed in [this issue](https://github.com/electron/electron/issues/18397).
|
||||
* Values sent over IPC are now serialized with Structured Clone Algorithm. [#20214](https://github.com/electron/electron/pull/20214)
|
||||
* Offscreen Rendering is currently disabled due to lack of a maintainer to work on this feature. It broke during the Chromium upgrade and was subsequently disabled. [#20772](https://github.com/electron/electron/issues/20772)
|
||||
|
||||
More information about these and future changes can be found on the [Planned Breaking Changes](https://github.com/electron/electron/blob/master/docs/breaking-changes.md) page.
|
||||
|
||||
## API Changes
|
||||
* `app` API changes:
|
||||
* Added `app.getApplicationNameForProtocol(url)`. [#20399](https://github.com/electron/electron/pull/20399)
|
||||
* Added `app.showAboutPanel()` and `app.setAboutPanelOptions(options)` support on Windows. [#19420](https://github.com/electron/electron/pull/19420)
|
||||
* `BrowserWindow` API changes:
|
||||
* Updated docs to note that BrowserWindow options `hasShadow` is available on all platforms [#20038](https://github.com/electron/electron/pull/20038)
|
||||
* Added `trafficLightPosition` option to BrowserWindow options to allow custom positioning for traffic light buttons. [#21781](https://github.com/electron/electron/pull/21781)
|
||||
* Added `accessibleTitle` option to BrowserWindow for setting the accessible window title [#19698](https://github.com/electron/electron/pull/19698)
|
||||
* `BrowserWindow.fromWebContents()` can now return null [#19983](https://github.com/electron/electron/pull/19983)
|
||||
* Added `BrowserWindow.getMediaSourceId()` and `BrowserWindow.moveAbove(mediaSourceId)`. [#18926](https://github.com/electron/electron/pull/18926)
|
||||
* Added support for `will-move` event on macOS. [#19641](https://github.com/electron/electron/pull/19641)
|
||||
* Documented previously undocumented `crashReporter.getCrashesDirectory()`. [#20417](https://github.com/electron/electron/pull/20417)
|
||||
* `dialog` API changes:
|
||||
* Added `dontAddToRecent` property to `dialog.showOpenDialog` and `dialog.showOpenDialogSync` to prevent documents from being added to recent documents on Windows in open dialogs. [#19669](https://github.com/electron/electron/pull/19669)
|
||||
* Added property customization to `dialog.showSaveDialog` and `dialog.showSaveDialogSync`. [#19672](https://github.com/electron/electron/pull/19672)
|
||||
* `Notification` API changes:
|
||||
* Added `timeoutType` option to allow Linux/Windows users to set the type of notification timeout. [#20153](https://github.com/electron/electron/pull/20153)
|
||||
* Added `urgency` option to set urgency on Linux notifications. [#20152](https://github.com/electron/electron/pull/20152)
|
||||
* `session` API changes:
|
||||
* Updated documentation on `session.setProxy(config)` and `session.setCertificateVerifyProc(proc)` to note optional options. [#19604](https://github.com/electron/electron/pull/19604)
|
||||
* Added `session.downloadURL(url)` to allow to triggering downloads without a BrowserWindow. [#19889](https://github.com/electron/electron/pull/19889)
|
||||
* Added support for HTTP preconnect resource hints via `session.preconnect(options)` and the `preconnect` event. [#18671](http://github.com/electron/electron/pull/18671)
|
||||
* Added `session.addWordToSpellCheckerDictionary` to allow custom words in the dictionary [#21297](http://github.com/electron/electron/pull/21297)
|
||||
* Added option to `shell.moveItemToTrash(fullPath[, deleteOnFail])` on macOS to specify what happens when moveItemToTrash fails. [#19700](https://github.com/electron/electron/pull/19700)
|
||||
* `systemPreferences` API changes:
|
||||
* Updated `systemPreferences.getColor(color)` documentation for macOS. [#20611](https://github.com/electron/electron/pull/20611)
|
||||
* Added `screen` media type to `systemPreferences.getMediaAccessStatus()`. [#20764](https://github.com/electron/electron/pull/20764)
|
||||
* Added `nativeTheme.themeSource` to allow apps to override Chromium and the OS's theme choice. [#19960](https://github.com/electron/electron/pull/19960)
|
||||
* TouchBar API changes:
|
||||
* Added `accessibilityLabel` property to `TouchBarButton` and `TouchBarLabel` to improve TouchBarButton/TouchBarLabel accessibility. [#20454](https://github.com/electron/electron/pull/20454)
|
||||
* Updated TouchBar related documentation [#19444](https://github.com/electron/electron/pull/19444)
|
||||
* `tray` API changes:
|
||||
* Added new options to `tray.displayBalloon()`: `iconType`, `largeIcon`, `noSound` and `respectQuietTime`. [#19544](https://github.com/electron/electron/pull/19544)
|
||||
* Added tray.removeBalloon(), which removes an already displayed balloon notification. [#19547](https://github.com/electron/electron/pull/19547)
|
||||
* Added tray.focus(), which returns focus to the taskbar notification area. feat: add tray.focus() [#19548](https://github.com/electron/electron/pull/19548)
|
||||
* `webContents` API changes:
|
||||
* Added `contents.executeJavaScriptInIsolatedWorld(worldId, scripts[, userGesture])` to expose executeJavaScriptInIsolatedWorld on the webContents API. [#21190](https://github.com/electron/electron/pull/21190)
|
||||
* Added methods to capture a hidden webContents. [#21679](https://github.com/electron/electron/pull/21679)
|
||||
* Added options to `webContents.print([options], [callback])` to enable customization of print page headers and footers. [#19688](https://github.com/electron/electron/pull/19688)
|
||||
* Added ability to inspect specific shared workers via `webContents.getAllSharedWorkers()` and `webContents.inspectSharedWorkerById(workerId)`. [#20389](https://github.com/electron/electron/pull/20389)
|
||||
* Added the support of `fitToPageEnabled` and `scaleFactor` options in WebContents.printToPDF(). [#20436](https://github.com/electron/electron/pull/20436)
|
||||
* Updated `webview.printToPDF` documentation to indicate return type is now Uint8Array. [#20505](https://github.com/electron/electron/pull/20505)
|
||||
|
||||
### Deprecated APIs
|
||||
The following APIs are now deprecated:
|
||||
* Deprecated the nonfunctional `visibleOnFullScreen` option within `BrowserWindow.setVisibleOnAllWorkspaces` prior to its removal in the next major release version. [#21732](https://github.com/electron/electron/pull/21732)
|
||||
* Deprecated `alternate-selected-control-text` on `systemPreferences.getColor(color)` for macOS. [#20611](https://github.com/electron/electron/pull/20611)
|
||||
* Deprecated `setLayoutZoomLevelLimits` on `webContents`, `webFrame`, and `<webview> Tag` because Chromium removed this capability. [#21296](https://github.com/electron/electron/pull/21296)
|
||||
* The default value of `false` for `app.allowRendererProcessReuse` is now deprecated. [#21287](https://github.com/electron/electron/pull/21287)
|
||||
* Deprecated `<webview>.getWebContents()` as it depends on the remote module. [#20726](https://github.com/electron/electron/pull/20726)
|
||||
|
||||
## End of Support for 5.x.y
|
||||
|
||||
Electron 5.x.y has reached end-of-support as per the project's
|
||||
[support policy](https://electronjs.org/docs/tutorial/support#supported-versions).
|
||||
Developers and applications are encouraged to upgrade to a newer version of Electron.
|
||||
|
||||
## App Feedback Program
|
||||
|
||||
We continue to use our [App Feedback Program](https://electronjs.org/blog/app-feedback-program) for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, [check out our blog post about the program](https://electronjs.org/blog/app-feedback-program).
|
||||
|
||||
## What's Next
|
||||
|
||||
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The [tentative 9.0.0 schedule](https://electronjs.org/docs/tutorial/electron-timelines) maps out key dates in the Electron 9 development life cycle. Also, [see our versioning document](https://electronjs.org/docs/tutorial/electron-versioning) for more detailed information about versioning in Electron.
|
||||
|
||||
For information on planned breaking changes in upcoming versions of Electron, [see our Planned Breaking Changes doc](https://github.com/electron/electron/blob/master/docs/breaking-changes.md).
|
||||
|
||||
### Deprecation of `remote` Module (Starting in Electron 9)
|
||||
Due to serious security liabilities, we are beginning plans to deprecate the [`remote` module](https://www.electronjs.org/docs/api/remote) starting in Electron 9. You can read and follow [this issue](https://github.com/electron/electron/issues/21408) that details our reasons for this and includes a proposed timeline for deprecation.
|
||||
|
|
@ -1,87 +0,0 @@
|
|||
---
|
||||
title: Electron 9.0.0
|
||||
author:
|
||||
- sofianguy
|
||||
- VerteDinde
|
||||
date: '2020-05-19'
|
||||
---
|
||||
|
||||
Electron 9.0.0 has been released! It includes upgrades to Chromium `83`, V8 `8.3`, and Node.js `12.14`. We've added several new API integrations for our spellchecker feature, enabled PDF viewer, and much more!
|
||||
|
||||
---
|
||||
|
||||
The Electron team is excited to announce the release of Electron 9.0.0! You can install it with npm via `npm install electron@latest` or download it from our [releases website](https://electronjs.org/releases/stable). The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
|
||||
|
||||
## Notable Changes
|
||||
|
||||
### Stack Changes
|
||||
|
||||
* Chromium `83.0.4103.64`
|
||||
* [New in Chrome 81](https://developers.google.com/web/updates/2020/04/nic81)
|
||||
* [Chrome 82 was skipped](https://chromereleases.googleblog.com/2020/03/chrome-and-chrome-os-release-updates.html)
|
||||
* [New in Chrome 83](https://developers.google.com/web/updates/2020/05/nic83)
|
||||
* Node.js `12.14.1`
|
||||
* [Node 12.14.1 blog post](https://nodejs.org/en/blog/release/v12.14.1/)
|
||||
* V8 `8.3`
|
||||
* [V8 8.1 blog post](https://v8.dev/blog/v8-release-81)
|
||||
* [V8 8.3 blog post](https://v8.dev/blog/v8-release-83)
|
||||
|
||||
### Highlight Features
|
||||
|
||||
* Multiple improvements to the spellchecker feature. See more details in [#22128](https://github.com/electron/electron/pull/22128) and [#22368](https://github.com/electron/electron/pull/22368).
|
||||
* Improved window events handler efficiency on Linux. [#23260](https://github.com/electron/electron/pull/23260).
|
||||
* Enable PDF viewer. [#22131](https://github.com/electron/electron/pull/22131).
|
||||
|
||||
See the [9.0.0 release notes](https://github.com/electron/electron/releases/tag/v9.0.0) for a full list of new features and changes.
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
* Deprecation warning when using `remote` without `enableRemoteModule: true`. [#21546](https://github.com/electron/electron/pull/21546)
|
||||
* This is the first step in our plans for deprecating the `remote` module and moving it to userland. You can read and follow [this issue](https://github.com/electron/electron/issues/21408) that details our reasons for this and includes a proposed timeline for deprecation.
|
||||
* Set `app.enableRendererProcessReuse` to true by default. [#22336](https://github.com/electron/electron/pull/22336)
|
||||
* This is continued work for a future requirement that native Node modules loaded in the renderer process be either [N-API](https://nodejs.org/api/n-api.html) or [Context Aware](https://nodejs.org/api/addons.html#addons_context_aware_addons). Full info and proposed timeline is detailed in [this issue](https://github.com/electron/electron/issues/18397).
|
||||
* Sending non-JavaScript objects over IPC now throws an exception. [#21560](https://github.com/electron/electron/pull/21560)
|
||||
* This behavior was depreciated in Electron 8.0. In Electron 9.0, the old serialization algorithm has been removed, and sending such non-serializable objects will now throw an "object could not be cloned" error.
|
||||
|
||||
More information about these and future changes can be found on the [Planned Breaking Changes](https://github.com/electron/electron/blob/master/docs/breaking-changes.md) page.
|
||||
|
||||
## API Changes
|
||||
|
||||
* `shell` API changes:
|
||||
* The `shell.openItem` API has been replaced with an asynchronous `shell.openPath API`. [proposal](https://github.com/electron/governance/blob/master/wg-api/spec-documents/shell-openitem.md)
|
||||
* `session`API changes:
|
||||
* Added `session.listWordsFromSpellCheckerDictionary` API to list custom words in the dictionary. [#22128](https://github.com/electron/electron/pull/22128)
|
||||
* Added `session.removeWordFromSpellCheckerDictionary` API to remove custom words in the dictionary. [#22368](https://github.com/electron/electron/pull/22368)
|
||||
* Added `session.serviceWorkerContext` API to access basic service worker info and receive console logs from service workers. [#22313](https://github.com/electron/electron/pull/22313)
|
||||
* `app` API changes:
|
||||
* Added a new force parameter to `app.focus()` on macOS to allow apps to forcefully take focus. [#23447](https://github.com/electron/electron/pull/23447)
|
||||
* `BrowserWindow` API changes:
|
||||
* Added support for property access to some getter/setter pairs on `BrowserWindow`. [#23208](https://github.com/electron/electron/pull/23208)
|
||||
|
||||
### Deprecated APIs
|
||||
|
||||
The following APIs are now deprecated or removed:
|
||||
|
||||
* `shell.openItem` API is now depreciated, and replaced with an asynchronous `shell.openPath API`.
|
||||
* `<webview>.getWebContents`, which was deprecated in Electron 8.0, is now removed.
|
||||
* `webFrame.setLayoutZoomLevelLimits`, which was deprecated in Electron 8.0, is now removed.
|
||||
|
||||
## End of Support for 6.x.y
|
||||
|
||||
Electron 6.x.y has reached end-of-support as per the project's
|
||||
[support policy](https://electronjs.org/docs/tutorial/support#supported-versions).
|
||||
Developers and applications are encouraged to upgrade to a newer version of Electron.
|
||||
|
||||
## What's Next
|
||||
|
||||
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The [tentative 10.0.0 schedule](https://electronjs.org/docs/tutorial/electron-timelines) maps out key dates in the Electron 10.0 development life cycle. Also, [see our versioning document](https://electronjs.org/docs/tutorial/electron-versioning) for more detailed information about versioning in Electron.
|
||||
|
||||
For information on planned breaking changes in upcoming versions of Electron, [see our Planned Breaking Changes doc](https://github.com/electron/electron/blob/master/docs/breaking-changes.md).
|
||||
|
||||
### Change the default of `contextIsolation` from `false` to `true` (Starting in Electron 10)
|
||||
|
||||
Without contextIsolation, any code running in a renderer process can quite easily reach into Electron internals or an app's preload script. That code can then perform privileged actions that Electron wants to keep restricted.
|
||||
|
||||
Changing this default improves the default security of Electron apps, so that apps will need to deliberately opt in to the insecure behaviour. Electron will depreciate the current default of `contextIsolation` in Electron 10.0, and change to the new default (`true`) in Electron 12.0.
|
||||
|
||||
For more information on `contextIsolation`, how to enable it easily and it's security benefits please see our dedicated [Context Isolation Document](https://github.com/electron/electron/blob/master/docs/tutorial/context-isolation.md).
|
||||
|
|
@ -1,99 +0,0 @@
|
|||
---
|
||||
title: API Changes Coming in Electron 1.0
|
||||
author: zcbenz
|
||||
date: '2015-11-17'
|
||||
---
|
||||
|
||||
Since the beginning of Electron, starting way back when it used to be called Atom-Shell, we have been experimenting with providing a nice cross-platform JavaScript API for Chromium's content module and native GUI components. The APIs started very organically, and over time we have made several changes to improve the initial designs.
|
||||
|
||||
---
|
||||
|
||||
Now with Electron gearing up for a 1.0 release, we'd like to take the opportunity for change by addressing the last niggling API details. The changes described below are included in **0.35.x**, with the old APIs reporting deprecation warnings so you can get up to date for the future 1.0 release. An Electron 1.0 won't be out for a few months so you have some time before these changes become breaking.
|
||||
|
||||
## Deprecation warnings
|
||||
|
||||
By default, warnings will show if you are using deprecated APIs. To turn them off you can set `process.noDeprecation` to `true`. To track the sources of deprecated API usages, you can set `process.throwDeprecation` to `true` to throw exceptions instead of printing warnings, or set `process.traceDeprecation` to `true` to print the traces of the deprecations.
|
||||
|
||||
## New way of using built-in modules
|
||||
|
||||
Built-in modules are now grouped into one module, instead of being separated into independent modules, so you can use them [without conflicts with other modules][issue-387]:
|
||||
|
||||
```javascript
|
||||
var app = require('electron').app
|
||||
var BrowserWindow = require('electron').BrowserWindow
|
||||
```
|
||||
|
||||
The old way of `require('app')` is still supported for backward compatibility, but you can also turn if off:
|
||||
|
||||
```javascript
|
||||
require('electron').hideInternalModules()
|
||||
require('app') // throws error.
|
||||
```
|
||||
|
||||
## An easier way to use the `remote` module
|
||||
|
||||
Because of the way using built-in modules has changed, we have made it easier to use main-process-side modules in renderer process. You can now just access `remote`'s attributes to use them:
|
||||
|
||||
```javascript
|
||||
// New way.
|
||||
var app = require('electron').remote.app
|
||||
var BrowserWindow = require('electron').remote.BrowserWindow
|
||||
```
|
||||
|
||||
Instead of using a long require chain:
|
||||
|
||||
```javascript
|
||||
// Old way.
|
||||
var app = require('electron').remote.require('app')
|
||||
var BrowserWindow = require('electron').remote.require('BrowserWindow')
|
||||
```
|
||||
|
||||
## Splitting the `ipc` module
|
||||
|
||||
The `ipc` module existed on both the main process and renderer process and the API was different on each side, which is quite confusing for new users. We have renamed the module to `ipcMain` in the main process, and `ipcRenderer` in the renderer process to avoid confusion:
|
||||
|
||||
```javascript
|
||||
// In main process.
|
||||
var ipcMain = require('electron').ipcMain
|
||||
```
|
||||
|
||||
```javascript
|
||||
// In renderer process.
|
||||
var ipcRenderer = require('electron').ipcRenderer
|
||||
```
|
||||
|
||||
And for the `ipcRenderer` module, an extra `event` object has been added when receiving messages, to match how messages are handled in `ipcMain` modules:
|
||||
|
||||
```javascript
|
||||
ipcRenderer.on('message', function (event) {
|
||||
console.log(event)
|
||||
})
|
||||
```
|
||||
|
||||
## Standardizing `BrowserWindow` options
|
||||
|
||||
The `BrowserWindow` options had different styles based on the options of other APIs, and were a bit hard to use in JavaScript because of the `-` in the names. They are now standardized to the traditional JavaScript names:
|
||||
|
||||
```javascript
|
||||
new BrowserWindow({ minWidth: 800, minHeight: 600 })
|
||||
```
|
||||
|
||||
## Following DOM's conventions for API names
|
||||
|
||||
The API names in Electron used to prefer camelCase for all API names, like `Url` to `URL`, but the DOM has its own conventions, and they prefer `URL` to `Url`, while using `Id` instead of `ID`. We have done the following API renames to match the DOM's styles:
|
||||
|
||||
* `Url` is renamed to `URL`
|
||||
* `Csp` is renamed to `CSP`
|
||||
|
||||
You will notice lots of deprecations when using Electron v0.35.0 for your app because of these changes. An easy way to fix them is to replace all instances of `Url` with `URL`.
|
||||
|
||||
## Changes to `Tray`'s event names
|
||||
|
||||
The style of `Tray` event names was a bit different from other modules so a rename has been done to make it match the others.
|
||||
|
||||
* `clicked` is renamed to `click`
|
||||
* `double-clicked` is renamed to `double-click`
|
||||
* `right-clicked` is renamed to `right-click`
|
||||
|
||||
[issue-387]: https://github.com/electron/electron/issues/387
|
||||
|
||||
|
|
@ -1,111 +0,0 @@
|
|||
---
|
||||
title: Electron Documentation
|
||||
author: jlord
|
||||
date: '2015-06-04'
|
||||
---
|
||||
|
||||
This week we've given Electron's documentation a home on [electronjs.org](https://electronjs.org). You can visit [/docs/latest](https://electronjs.org/docs/latest) for the latest set of docs. We'll keep versions of older docs, too, so you're able to visit [/docs/vX.XX.X](https://electronjs.org/docs/v0.26.0) for the docs that correlate to the version you're using.
|
||||
|
||||
---
|
||||
|
||||
You can visit [/docs](https://electronjs.org/docs) to see what versions are available or [/docs/all](https://electronjs.org/docs/all) to see the latest version of docs all on one page (nice for `cmd` + `f` searches).
|
||||
|
||||
If you'd like to contribute to the docs content, you can do so in the [Electron repository](https://github.com/electron/electron/tree/master/docs), where the docs are fetched from. We fetch them for each minor release and add them to the [Electron site repository](http://github.com/electron/electronjs.org), which is made with [Jekyll](http://jekyllrb.com).
|
||||
|
||||
If you're interested in learning more about how we pull the docs from one repository to another continue reading below. Otherwise, enjoy the [docs](https://electronjs.org/latest)!
|
||||
|
||||
## The Technical Bits
|
||||
|
||||
We're preserving the documentation within the Electron core repository as is. This means that [electron/electron](http://github.com/electron/electron) will always have the latest version of the docs. When new versions of Electron are released, we duplicate them over on the Electron website repository, [electron/electronjs.org](http://github.com/electron/electronjs.org).
|
||||
|
||||
### script/docs
|
||||
|
||||
To fetch the docs we run a [script](https://github.com/electron/electronjs.org/blob/0205b5ab26c96a95121bc564c5824f92108677e0/script/docs) with a command line interface of `script/docs vX.XX.X` with or without the `--latest` option (depending on if the version you're importing is the latest version). Our [script for fetching docs](https://github.com/electron/electronjs.org/blob/0205b5ab26c96a95121bc564c5824f92108677e0/lib/fetch-docs.js) uses a few interesting Node modules:
|
||||
|
||||
- [`nugget`](http://npmjs.com/nugget) for [getting the release tarball](https://github.com/electron/electronjs.org/blob/0205b5ab26c96a95121bc564c5824f92108677e0/lib/fetch-docs.js#L40-L43) and saving it to a temporay directory.
|
||||
- [`gunzip-maybe`](http://npmsjs.com/gunzip-maybe) to [unzip the tarball](https://github.com/electron/electronjs.org/blob/0205b5ab26c96a95121bc564c5824f92108677e0/lib/fetch-docs.js#L95).
|
||||
- [`tar-fs`](http://npmjs.com/tar-fs) for [streaming just the `/docs` directory](https://github.com/electron/electronjs.org/blob/0205b5ab26c96a95121bc564c5824f92108677e0/lib/fetch-docs.js#L63-L65) from the tarball and [filtering and processing the files](https://github.com/electron/electronjs.org/blob/0205b5ab26c96a95121bc564c5824f92108677e0/lib/fetch-docs.js#L68-L78) (with the help of [`through2`](http://npmjs.com/through2)) so that they work nicely with our Jekyll site (more on that below).
|
||||
|
||||
[Tests](https://github.com/electron/electronjs.org/tree/gh-pages/spec) help us know that all the bits and pieces landed as expected.
|
||||
|
||||
### Jekyll
|
||||
|
||||
The Electron website is a Jekyll site and we make use of the [Collections](http://jekyllrb.com/docs/collections/) feature for the docs with a structure like this:
|
||||
|
||||
```bash
|
||||
electron.atom.io
|
||||
└── _docs
|
||||
├── latest
|
||||
├── v0.27.0
|
||||
├── v0.26.0
|
||||
├── so on
|
||||
└── so forth
|
||||
```
|
||||
|
||||
#### Front matter
|
||||
|
||||
For Jekyll to render each page it needs at least empty front matter. We're going to make use of front matter on all of our pages so while we're streaming out the `/docs` directory we check to see if a file is the `README.md` file (in which case it receives one front matter configuration) or if it is any other file with a markdown extension (in which case it receives slightly different front matter).
|
||||
|
||||
Each page receives this set of front matter variables:
|
||||
|
||||
```yaml
|
||||
---
|
||||
version: v0.27.0
|
||||
category: Tutorial
|
||||
title: 'Quick Start'
|
||||
source_url: 'https://github.com/electron/electron/blob/master/docs/tutorial/quick-start.md'
|
||||
---
|
||||
```
|
||||
|
||||
The `README.md` gets an additional `permalink` so that has a URL has a common root of `index.html` rather than an awkward `/readme/`.
|
||||
|
||||
```yaml
|
||||
permalink: /docs/v0.27.0/index.html
|
||||
```
|
||||
|
||||
#### Config and Redirects
|
||||
|
||||
In the site's `_config.yml` file a variable `latest_version` is set every time the `--latest` flag is used when fetching docs. We also add a list of all the versions that have been added to the site as well as the permalink we'd like for the entire docs collection.
|
||||
|
||||
```yaml
|
||||
latest_version: v0.27.0
|
||||
available_versions:
|
||||
- v0.27.0
|
||||
collections:
|
||||
docs: {output: true, permalink: '/docs/:path/'}
|
||||
```
|
||||
|
||||
The file `latest.md` in our site root is empty except for this front matter which allows users to see the index (aka `README`) of the latest version of docs by visiting this URL, [electron.atom.io/docs/latest](https://electronjs.org/docs/latest), rather than using the latest version number specifically (though you can do that, too).
|
||||
|
||||
```yaml
|
||||
---
|
||||
permalink: /docs/latest/
|
||||
redirect_to: /docs/{{ site.data.releases[0].version }}
|
||||
---
|
||||
```
|
||||
|
||||
#### Layouts
|
||||
|
||||
In the `docs.html` layout template we use conditionals to either show or hide information in the header and breadcrumb.
|
||||
|
||||
```html
|
||||
{% raw %}
|
||||
{% if page.category != 'ignore' %}
|
||||
<h6 class='docs-breadcrumb'>{{ page.version }} / {{ page.category }}
|
||||
{% if page.title != 'README' %} / {{ page.title }} {% endif %}</h6>
|
||||
{% endif %}
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
To create a page showing the versions that are available we just loop through the list in our config on a file, `versions.md`, in the site's root. Also we give this page a permalink: `/docs/`
|
||||
|
||||
```html
|
||||
{% raw %}
|
||||
{% for version in site.available_versions %}
|
||||
- [{{ version }}](/docs/{{ version }})
|
||||
{% endfor %}
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
Hope you enjoyed these technical bits! If you're interested in more information on using Jekyll for documentation sites, checkout how GitHub's docs team publishes [GitHub's docs on Jekyll](https://github.com/blog/1939-how-github-uses-github-to-document-github).
|
||||
|
||||
|
|
@ -1,176 +0,0 @@
|
|||
---
|
||||
title: 'Electron Internals: Building Chromium as a Library'
|
||||
author: zcbenz
|
||||
date: '2017-03-03'
|
||||
---
|
||||
|
||||
Electron is based on Google's open-source Chromium, a project that is not
|
||||
necessarily designed to be used by other projects. This post introduces
|
||||
how Chromium is built as a library for Electron's use, and how the build
|
||||
system has evolved over the years.
|
||||
|
||||
---
|
||||
|
||||
## Using CEF
|
||||
|
||||
The Chromium Embedded Framework (CEF) is a project that turns Chromium into
|
||||
a library, and provides stable APIs based on Chromium's codebase. Very
|
||||
early versions of Atom editor and NW.js used CEF.
|
||||
|
||||
To maintain a stable API, CEF hides all the details of Chromium
|
||||
and wraps Chromium's APIs with its own interface. So when we needed to
|
||||
access underlying Chromium APIs, like integrating Node.js into web pages, the
|
||||
advantages of CEF became blockers.
|
||||
|
||||
So in the end both Electron and NW.js switched to using Chromium's APIs
|
||||
directly.
|
||||
|
||||
## Building as part of Chromium
|
||||
|
||||
Even though Chromium does not officially support outside projects, the codebase
|
||||
is modular and it is easy to build a minimal browser based on Chromium. The core
|
||||
module providing the browser interface is called Content Module.
|
||||
|
||||
To develop a project with Content Module, the easiest way is to build the
|
||||
project as part of Chromium. This can be done by first checking out Chromium's
|
||||
source code, and then adding the project to Chromium's `DEPS` file.
|
||||
|
||||
NW.js and very early versions of Electron are using this way for building.
|
||||
|
||||
The downside is, Chromium is a very large codebase and requires very powerful
|
||||
machines to build. For normal laptops, that can take more than 5 hours.
|
||||
So this greatly impacts the number of developers that can contribute to the
|
||||
project, and it also makes development slower.
|
||||
|
||||
## Building Chromium as a single shared library
|
||||
|
||||
As a user of Content Module, Electron does not need to modify Chromium's code
|
||||
under most cases, so an obvious way to improve the building of Electron is to
|
||||
build Chromium as a shared library, and then link with it in Electron. In this
|
||||
way developers no longer need to build all off Chromium when contributing to
|
||||
Electron.
|
||||
|
||||
The [libchromiumcontent] project was created by
|
||||
[@aroben](https://github.com/aroben) for this purpose. It builds the Content
|
||||
Module of Chromium as a shared library, and then provides Chromium's headers
|
||||
and prebuilt binaries for download. The code of the initial version of
|
||||
libchromiumcontent can be found [in this link][libcc-classic].
|
||||
|
||||
The [brightray] project was also born as part of libchromiumcontent,
|
||||
which provides a thin layer around Content Module.
|
||||
|
||||
By using libchromiumcontent and brightray together, developers can
|
||||
quickly build a browser without getting into the details of building Chromium.
|
||||
And it removes the requirement of a fast network and powerful machine for building
|
||||
the project.
|
||||
|
||||
Apart from Electron, there were also other Chromium-based projects built in this
|
||||
way, like the [Breach browser][breach].
|
||||
|
||||
## Filtering exported symbols
|
||||
|
||||
On Windows there is a limitation of how many symbols one shared library can
|
||||
export. As the codebase of Chromium grew, the number of symbols exported in
|
||||
libchromiumcontent soon exceeded the limitation.
|
||||
|
||||
The solution was to filter out unneeded symbols when generating the DLL file.
|
||||
It worked by [providing a `.def` file to the linker][libcc-def], and then using
|
||||
a script to [judge whether symbols under a namespace should be
|
||||
exported][libcc-filter].
|
||||
|
||||
By taking this approach, though Chromium kept adding new exported symbols,
|
||||
libchromiumcontent could still generate shared library files by stripping more
|
||||
symbols.
|
||||
|
||||
## Component build
|
||||
|
||||
Before talking about the next steps taken in libchromiumcontent, it is important
|
||||
to introduce the concept of component build in Chromium first.
|
||||
|
||||
As a huge project, the linking step takes very long in Chromium when building.
|
||||
Normally when a developer makes a small change, it can take 10 minutes to see the
|
||||
final output. To solve this, Chromium introduced component build, which builds
|
||||
each module in Chromium as separated shared libraries, so the time spent in the
|
||||
final linking step becomes unnoticeable.
|
||||
|
||||
## Shipping raw binaries
|
||||
|
||||
With Chromium continuing to grow, there were so many exported symbols in
|
||||
Chromium that even the symbols of Content Module and Webkit were more than the
|
||||
limitation. It was impossible to generate a usable shared library by simply
|
||||
stripping symbols.
|
||||
|
||||
In the end, we had to [ship the raw binaries of Chromium][libcc-gyp] instead of
|
||||
generating a single shared library.
|
||||
|
||||
As introduced earlier there are two build modes in Chromium. As a result of
|
||||
shipping raw binaries, we have to ship two different distributions of binaries
|
||||
in libchromiumcontent. One is called `static_library` build, which includes
|
||||
all static libraries of each module generated by the normal build of Chromium.
|
||||
The other is `shared_library`, which includes all shared libraries of each
|
||||
module generated by the component build.
|
||||
|
||||
In Electron, the Debug version is linked with the `shared_library` version of
|
||||
libchromiumcontent, because it is small to download and takes little time
|
||||
when linking the final executable. And the Release version of Electron is
|
||||
linked with the `static_library` version of libchromiumcontent, so the compiler
|
||||
can generate full symbols which are important for debugging, and the linker
|
||||
can do much better optimization since it knows which object files are needed
|
||||
and which are not.
|
||||
|
||||
So for normal development, developers only need to build the Debug version,
|
||||
which does not require a good network or powerful machine. Though the Release
|
||||
version then requires much better hardware to build, it can generate better
|
||||
optimized binaries.
|
||||
|
||||
## The `gn` update
|
||||
|
||||
Being one of the largest projects in the world, most normal systems are not
|
||||
suitable for building Chromium, and the Chromium team develops their own build
|
||||
tools.
|
||||
|
||||
Earlier versions of Chromium were using `gyp` as a build system, but it suffers
|
||||
from being slow, and its configuration file becomes hard to understand for complex
|
||||
projects. After years of development, Chromium switched to `gn` as a
|
||||
build system, which is much faster and has a clear architecture.
|
||||
|
||||
One of the improvements of `gn` is to introduce `source_set`, which represents
|
||||
a group of object files. In `gyp`, each module was represented by either
|
||||
`static_library` or `shared_library`, and for the normal build of Chromium,
|
||||
each module generated a static library and they were linked together in the
|
||||
final executable. By using `gn`, each module now only generates a bunch of
|
||||
object files, and the final executable just links all the object files together,
|
||||
so the intermediate static library files are no longer generated.
|
||||
|
||||
This improvement however made great trouble to libchromiumcontent, because
|
||||
the intermediate static library files were actually needed by libchromiumcontent.
|
||||
|
||||
The first try to solve this was to [patch `gn` to generate static library
|
||||
files][libcc-gn-hack], which solved the problem, but was far from a decent
|
||||
solution.
|
||||
|
||||
The second try was made by [@alespergl](https://github.com/alespergl) to
|
||||
[produce custom static libraries from the list of object files][libcc-gn].
|
||||
It used a trick to first run a dummy build to collect a list of generated
|
||||
object files, and then actually build the static libraries by feeding
|
||||
`gn` with the list. It only made minimal changes to Chromium's source
|
||||
code, and kept Electron's building architecture still.
|
||||
|
||||
## Summary
|
||||
|
||||
As you can see, compared to building Electron as part of Chromium, building
|
||||
Chromium as a library takes greater efforts and requires continuous
|
||||
maintenance. However the latter removes the requirement of powerful hardware
|
||||
to build Electron, thus enabling a much larger range of developers to build and
|
||||
contribute to Electron. The effort is totally worth it.
|
||||
|
||||
[libchromiumcontent]: https://github.com/electron/libchromiumcontent
|
||||
[brightray]: https://github.com/electron/brightray
|
||||
[breach]: https://www.quora.com/Is-Breach-Browser-still-in-development
|
||||
[libcc-classic]: https://github.com/electron/libchromiumcontent/tree/873daa8c57efa053d48aa378ac296b0a1206822c
|
||||
[libcc-def]: https://github.com/electron/libchromiumcontent/pull/11/commits/85ca0f60208eef2c5013a29bb4cf3d21feb5030b
|
||||
[libcc-filter]: https://github.com/electron/libchromiumcontent/pull/47/commits/d2fed090e47392254f2981a56fe4208938e538cd
|
||||
[libcc-gyp]: https://github.com/electron/libchromiumcontent/pull/98
|
||||
[libcc-gn-hack]: https://github.com/electron/libchromiumcontent/pull/239
|
||||
[libcc-gn]: https://github.com/electron/libchromiumcontent/pull/249
|
||||
|
||||
|
|
@ -1,85 +0,0 @@
|
|||
---
|
||||
title: 'Electron Internals: Message Loop Integration'
|
||||
author: zcbenz
|
||||
date: '2016-07-28'
|
||||
---
|
||||
|
||||
This is the first post of a series that explains the internals of Electron. This
|
||||
post introduces how Node's event loop is integrated with Chromium in Electron.
|
||||
|
||||
---
|
||||
|
||||
There had been many attempts to use Node for GUI programming, like
|
||||
[node-gui][node-gui] for GTK+ bindings, and [node-qt][node-qt] for QT bindings.
|
||||
But none of them work in production because GUI toolkits have their own message
|
||||
loops while Node uses libuv for its own event loop, and the main thread can only
|
||||
run one loop at the same time. So the common trick to run GUI message loop in
|
||||
Node is to pump the message loop in a timer with very small interval, which
|
||||
makes GUI interface response slow and occupies lots of CPU resources.
|
||||
|
||||
During the development of Electron we met the same problem, though in a
|
||||
reversed way: we had to integrate Node's event loop into Chromium's message
|
||||
loop.
|
||||
|
||||
## The main process and renderer process
|
||||
|
||||
Before we dive into the details of message loop integration, I'll first explain
|
||||
the multi-process architecture of Chromium.
|
||||
|
||||
In Electron there are two types of processes: the main process and the renderer
|
||||
process (this is actually extremely simplified, for a complete view please see
|
||||
[Multi-process Architecture][multi-process]). The main process is responsible
|
||||
for GUI work like creating windows, while the renderer process only deals with
|
||||
running and rendering web pages.
|
||||
|
||||
Electron allows using JavaScript to control both the main process and renderer
|
||||
process, which means we have to integrate Node into both processes.
|
||||
|
||||
## Replacing Chromium's message loop with libuv
|
||||
|
||||
My first try was reimplementing Chromium's message loop with libuv.
|
||||
|
||||
It was easy for the renderer process, since its message loop only listened to
|
||||
file descriptors and timers, and I only needed to implement the interface with
|
||||
libuv.
|
||||
|
||||
However it was significantly more difficult for the main process. Each platform
|
||||
has its own kind of GUI message loops. macOS Chromium uses `NSRunLoop`,
|
||||
whereas Linux uses glib. I tried lots of hacks to extract the
|
||||
underlying file descriptors out of the native GUI message loops, and then fed
|
||||
them to libuv for iteration, but I still met edge cases that did not work.
|
||||
|
||||
So finally I added a timer to poll the GUI message loop in a small interval. As
|
||||
a result the process took a constant CPU usage, and certain operations had
|
||||
long delays.
|
||||
|
||||
## Polling Node's event loop in a separate thread
|
||||
|
||||
As libuv matured, it was then possible to take another approach.
|
||||
|
||||
The concept of backend fd was introduced into libuv, which is a file descriptor
|
||||
(or handle) that libuv polls for its event loop. So by polling the backend fd it
|
||||
is possible to get notified when there is a new event in libuv.
|
||||
|
||||
So in Electron I created a separate thread to poll the backend fd, and since I
|
||||
was using the system calls for polling instead of libuv APIs, it was thread
|
||||
safe. And whenever there was a new event in libuv's event loop, a message would
|
||||
be posted to Chromium's message loop, and the events of libuv would then be
|
||||
processed in the main thread.
|
||||
|
||||
In this way I avoided patching Chromium and Node, and the same code was used in
|
||||
both the main and renderer processes.
|
||||
|
||||
## The code
|
||||
|
||||
You can find the implemention of the message loop integration in the
|
||||
`node_bindings` files under [`electron/atom/common/`][node-bindings]. It can be
|
||||
easily reused for projects that want to integrate Node.
|
||||
|
||||
*Update: Implementation moved to [`electron/shell/common/node_bindings.cc`][node-bindings-updated].*
|
||||
|
||||
[node-gui]: https://github.com/zcbenz/node-gui
|
||||
[node-qt]: https://github.com/arturadib/node-qt
|
||||
[multi-process]: http://dev.chromium.org/developers/design-documents/multi-process-architecture
|
||||
[node-bindings]: https://github.com/electron/electron/tree/master/atom/common
|
||||
[node-bindings-updated]: https://github.com/electron/electron/blob/master/shell/common/node_bindings.cc
|
||||
|
|
@ -1,117 +0,0 @@
|
|||
---
|
||||
title: 'Electron Internals: Using Node as a Library'
|
||||
author: zcbenz
|
||||
date: '2016-08-08'
|
||||
---
|
||||
|
||||
This is the second post in an ongoing series explaining the internals of
|
||||
Electron. Check out the [first post][event-loop] about event loop integration
|
||||
if you haven't already.
|
||||
|
||||
Most people use [Node](https://nodejs.org) for server-side applications, but because of Node's rich
|
||||
API set and thriving community, it is also a great fit for an embedded library.
|
||||
This post explains how Node is used as a library in Electron.
|
||||
|
||||
---
|
||||
|
||||
## Build system
|
||||
|
||||
Both Node and Electron use [`GYP`][gyp] as their build systems. If you want to embed
|
||||
Node inside your app, you have to use it as your build system too.
|
||||
|
||||
New to `GYP`? Read [this guide][gyp-docs] before you continue further in this post.
|
||||
|
||||
## Node's flags
|
||||
|
||||
The [`node.gyp`][nodegyp] file in Node's source code directory describes how Node
|
||||
is built, along with lots of [`GYP`][gyp] variables controlling which parts of
|
||||
Node are enabled and whether to open certain configurations.
|
||||
|
||||
To change the build flags, you need to set the variables in the `.gypi` file of
|
||||
your project. The `configure` script in Node can generate some common
|
||||
configurations for you, for example running `./configure --shared` will generate
|
||||
a `config.gypi` with variables instructing Node to be built as a shared library.
|
||||
|
||||
Electron does not use the `configure` script since it has its own build scripts.
|
||||
The configurations for Node are defined in the [`common.gypi`][commongypi] file
|
||||
in Electron's root source code directory.
|
||||
|
||||
## Link Node with Electron
|
||||
|
||||
In Electron, Node is being linked as a shared library by setting the `GYP`
|
||||
variable `node_shared` to `true`, so Node's build type will be changed from
|
||||
`executable` to `shared_library`, and the source code containing the Node's `main`
|
||||
entry point will not be compiled.
|
||||
|
||||
Since Electron uses the V8 library shipped with Chromium, the V8 library
|
||||
included in Node's source code is not used. This is done by setting both
|
||||
`node_use_v8_platform` and `node_use_bundled_v8` to `false`.
|
||||
|
||||
## Shared library or static library
|
||||
|
||||
When linking with Node, there are two options: you can either build Node as a
|
||||
static library and include it in the final executable, or you can build it as a
|
||||
shared library and ship it alongside the final executable.
|
||||
|
||||
In Electron, Node was built as a static library for a long time. This made the
|
||||
build simple, enabled the best compiler optimizations, and allowed Electron to
|
||||
be distributed without an extra `node.dll` file.
|
||||
|
||||
However, this changed after Chrome switched to use [BoringSSL][boringssl]. BoringSSL is a
|
||||
fork of [OpenSSL][openssl] that removes several unused APIs and changes many existing
|
||||
interfaces. Because Node still uses OpenSSL, the compiler would generate numerous
|
||||
linking errors due to conflicting symbols if they were linked together.
|
||||
|
||||
Electron couldn't use BoringSSL in Node, or use OpenSSL in Chromium, so the only
|
||||
option was to switch to building Node as a shared library, and
|
||||
[hide the BoringSSL and OpenSSL symbols][openssl-hide] in the components of each.
|
||||
|
||||
This change brought Electron some positive side effects. Before this
|
||||
change, you could not rename the executable file of Electron on Windows if you
|
||||
used native modules because the name of the executable was hard coded in the
|
||||
import library. After Node was built as a shared library, this limitation was gone
|
||||
because all native modules were linked to `node.dll`, whose name didn't need to
|
||||
be changed.
|
||||
|
||||
## Supporting native modules
|
||||
|
||||
[Native modules][native-modules] in Node work by defining an entry function for Node to load,
|
||||
and then searching the symbols of V8 and libuv from Node. This is a bit
|
||||
troublesome for embedders because by default the symbols of V8 and libuv are
|
||||
hidden when building Node as a library and native modules will fail to load
|
||||
because they cannot find the symbols.
|
||||
|
||||
So in order to make native modules work, the V8 and libuv symbols
|
||||
were exposed in Electron. For V8 this is done by [forcing all
|
||||
symbols in Chromium's configuration file to be exposed][v8-expose]. For libuv,
|
||||
it is achieved by [setting the `BUILDING_UV_SHARED=1` definition][libuv-expose].
|
||||
|
||||
## Starting Node in your app
|
||||
|
||||
After all the work of building and linking with Node, the final step is to run
|
||||
Node in your app.
|
||||
|
||||
Node doesn't provide many public APIs for embedding itself into other apps.
|
||||
Usually, you can just call [`node::Start` and `node::Init`][node-start] to start
|
||||
a new instance of Node. However, if you are building a complex app based on Node,
|
||||
you have to use APIs like `node::CreateEnvironment` to precisely control every
|
||||
step.
|
||||
|
||||
In Electron, Node is started in two modes: the standalone mode that runs in the
|
||||
main process, which is similar to official Node binaries, and the embedded mode
|
||||
which inserts Node APIs into web pages. The details of this will be explained
|
||||
in a future post.
|
||||
|
||||
[gyp]: https://gyp.gsrc.io
|
||||
[nodegyp]: https://github.com/nodejs/node/blob/v6.3.1/node.gyp
|
||||
[commongypi]: https://github.com/electron/electron/blob/master/common.gypi
|
||||
[openssl-hide]: https://github.com/electron/electron/blob/v1.3.2/common.gypi#L209-L218
|
||||
[v8-expose]: https://github.com/electron/libchromiumcontent/blob/v51.0.2704.61/chromiumcontent/chromiumcontent.gypi#L104-L122
|
||||
[libuv-expose]: https://github.com/electron/electron/blob/v1.3.2/common.gypi#L219-L228
|
||||
[node-start]: https://github.com/nodejs/node/blob/v6.3.1/src/node.h#L187-L191
|
||||
[event-loop]: https://electronjs.org/blog/2016/07/28/electron-internals-node-integration
|
||||
[gyp-docs]: https://gyp.gsrc.io/docs/UserDocumentation.md
|
||||
[native-modules]: https://nodejs.org/api/addons.html
|
||||
[boringssl]: https://boringssl.googlesource.com/boringssl
|
||||
[openssl]: https://www.openssl.org
|
||||
|
||||
|
|
@ -1,217 +0,0 @@
|
|||
---
|
||||
title: 'Electron Internals: Weak References'
|
||||
author: zcbenz
|
||||
date: '2016-09-20'
|
||||
---
|
||||
|
||||
As a language with garbage collection, JavaScript frees users from managing
|
||||
resources manually. But because Electron hosts this environment, it has to be
|
||||
very careful avoiding both memory and resources leaks.
|
||||
|
||||
This post introduces the concept of weak references and how they are used to
|
||||
manage resources in Electron.
|
||||
|
||||
---
|
||||
|
||||
## Weak references
|
||||
|
||||
In JavaScript, whenever you assign an object to a variable, you are adding a
|
||||
reference to the object. As long as there is a reference to the object, it will
|
||||
always be kept in memory. Once all references to the object are gone, i.e. there
|
||||
are no longer variables storing the object, the JavaScript engine will recoup
|
||||
the memory on next garbage collection.
|
||||
|
||||
A weak reference is a reference to an object that allows you to get the object
|
||||
without effecting whether it will be garbage collected or not. You will also get
|
||||
notified when the object is garbage collected. It then becomes possible to
|
||||
manage resources with JavaScript.
|
||||
|
||||
Using the `NativeImage` class in Electron as an example, every time you call the
|
||||
`nativeImage.create()` API, a `NativeImage` instance is returned and it is
|
||||
storing the image data in C++. Once you are done with the instance and the
|
||||
JavaScript engine (V8) has garbage collected the object, code in C++ will be
|
||||
called to free the image data in memory, so there is no need for users manage
|
||||
this manually.
|
||||
|
||||
Another example is [the window disappearing problem][window-disappearing], which
|
||||
visually shows how the window is garbage collected when all the references to it
|
||||
are gone.
|
||||
|
||||
## Testing weak references in Electron
|
||||
|
||||
There is no way to directly test weak references in raw JavaScript since the
|
||||
language doesn't have a way to assign weak references. The only API in
|
||||
JavaScript related to weak references is [WeakMap][WeakMap], but since it only
|
||||
creates weak-reference keys, it is impossible to know when an object has been
|
||||
garbage collected.
|
||||
|
||||
In versions of Electron prior to v0.37.8, you can use the internal
|
||||
`v8Util.setDestructor` API to test weak references, which adds a weak reference
|
||||
to the passed object and calls the callback when the object is garbage collected:
|
||||
|
||||
```javascript
|
||||
// Code below can only run on Electron < v0.37.8.
|
||||
var v8Util = process.atomBinding('v8_util')
|
||||
|
||||
var object = {}
|
||||
v8Util.setDestructor(object, function () {
|
||||
console.log('The object is garbage collected')
|
||||
})
|
||||
|
||||
// Remove all references to the object.
|
||||
object = undefined
|
||||
// Manually starts a GC.
|
||||
gc()
|
||||
// Console prints "The object is garbage collected".
|
||||
```
|
||||
|
||||
Note that you have to start Electron with the `--js-flags="--expose_gc"` command
|
||||
switch to expose the internal `gc` function.
|
||||
|
||||
The API was removed in later versions because V8 actually does not allow running
|
||||
JavaScript code in the destructor and in later versions doing so would cause
|
||||
random crashes.
|
||||
|
||||
## Weak references in the `remote` module
|
||||
|
||||
Apart from managing native resources with C++, Electron also needs weak
|
||||
references to manage JavaScript resources. An example is Electron's `remote`
|
||||
module, which is a [Remote Procedure Call][remote-procedure-call] (RPC) module
|
||||
that allows using objects in the main process from renderer processes.
|
||||
|
||||
One key challenge with the `remote` module is to avoid memory leaks. When users
|
||||
acquire a remote object in the renderer process, the `remote` module must
|
||||
guarantee the object continues to live in the main process until the references
|
||||
in the renderer process are gone. Additionally, it also has to make sure the
|
||||
object can be garbage collected when there are no longer any reference to it in
|
||||
renderer processes.
|
||||
|
||||
For example, without proper implementation, following code would cause memory
|
||||
leaks quickly:
|
||||
|
||||
```javascript
|
||||
const {remote} = require('electron')
|
||||
|
||||
for (let i = 0; i < 10000; ++i) {
|
||||
remote.nativeImage.createEmpty()
|
||||
}
|
||||
```
|
||||
|
||||
The resource management in the `remote` module is simple. Whenever an object is
|
||||
requested, a message is sent to the main process and Electron will store
|
||||
the object in a map and assign an ID for it, then send the ID back to the
|
||||
renderer process. In the renderer process, the `remote` module will receive
|
||||
the ID and wrap it with a proxy object and when the proxy object is garbage
|
||||
collected, a message will be sent to the main process to free the object.
|
||||
|
||||
Using `remote.require` API as an example, a simplified implementation looks
|
||||
like this:
|
||||
|
||||
```javascript
|
||||
remote.require = function (name) {
|
||||
// Tell the main process to return the metadata of the module.
|
||||
const meta = ipcRenderer.sendSync('REQUIRE', name)
|
||||
// Create a proxy object.
|
||||
const object = metaToValue(meta)
|
||||
// Tell the main process to free the object when the proxy object is garbage
|
||||
// collected.
|
||||
v8Util.setDestructor(object, function () {
|
||||
ipcRenderer.send('FREE', meta.id)
|
||||
})
|
||||
return object
|
||||
}
|
||||
```
|
||||
|
||||
In the main process:
|
||||
|
||||
```javascript
|
||||
const map = {}
|
||||
const id = 0
|
||||
|
||||
ipcMain.on('REQUIRE', function (event, name) {
|
||||
const object = require(name)
|
||||
// Add a reference to the object.
|
||||
map[++id] = object
|
||||
// Convert the object to metadata.
|
||||
event.returnValue = valueToMeta(id, object)
|
||||
})
|
||||
|
||||
ipcMain.on('FREE', function (event, id) {
|
||||
delete map[id]
|
||||
})
|
||||
```
|
||||
|
||||
## Maps with weak values
|
||||
|
||||
With the previous simple implementation, every call in the `remote` module will
|
||||
return a new remote object from the main process, and each remote object
|
||||
represents a reference to the object in the main process.
|
||||
|
||||
The design itself is fine, but the problem is when there are multiple calls to
|
||||
receive the same object, multiple proxy objects will be created and for
|
||||
complicated objects this can add huge pressure on memory usage and garbage
|
||||
collection.
|
||||
|
||||
For example, the following code:
|
||||
|
||||
```javascript
|
||||
const {remote} = require('electron')
|
||||
|
||||
for (let i = 0; i < 10000; ++i) {
|
||||
remote.getCurrentWindow()
|
||||
}
|
||||
```
|
||||
|
||||
It first uses a lot of memory creating proxy objects and then occupies
|
||||
the CPU (Central Processing Unit) for garbage collecting them and sending IPC
|
||||
messages.
|
||||
|
||||
An obvious optimization is to cache the remote objects: when there is already
|
||||
a remote object with the same ID, the previous remote object will be returned
|
||||
instead of creating a new one.
|
||||
|
||||
This is not possible with the API in JavaScript core. Using the normal map
|
||||
to cache objects will prevent V8 from garbage collecting the objects, while the
|
||||
[WeakMap][WeakMap] class can only use objects as weak keys.
|
||||
|
||||
To solve this, a map type with values as weak references is added, which is
|
||||
perfect for caching objects with IDs. Now the `remote.require` looks like
|
||||
this:
|
||||
|
||||
```javascript
|
||||
const remoteObjectCache = v8Util.createIDWeakMap()
|
||||
|
||||
remote.require = function (name) {
|
||||
// Tell the main process to return the meta data of the module.
|
||||
...
|
||||
if (remoteObjectCache.has(meta.id))
|
||||
return remoteObjectCache.get(meta.id)
|
||||
// Create a proxy object.
|
||||
...
|
||||
remoteObjectCache.set(meta.id, object)
|
||||
return object
|
||||
}
|
||||
```
|
||||
|
||||
Note that the `remoteObjectCache` stores objects as weak references, so there
|
||||
is no need to delete the key when the object is garbage collected.
|
||||
|
||||
## Native code
|
||||
|
||||
For people interested in the C++ code of weak references in Electron, it can be
|
||||
found in following files:
|
||||
|
||||
The `setDestructor` API:
|
||||
|
||||
* [`object_life_monitor.cc`](https://github.com/electron/electron/blob/v1.3.4/atom/common/api/object_life_monitor.cc)
|
||||
* [`object_life_monitor.h`](https://github.com/electron/electron/blob/v1.3.4/atom/common/api/object_life_monitor.h)
|
||||
|
||||
The `createIDWeakMap` API:
|
||||
|
||||
* [`key_weak_map.h`](https://github.com/electron/electron/blob/v1.3.4/atom/common/key_weak_map.h)
|
||||
* [`atom_api_key_weak_map.h`](https://github.com/electron/electron/blob/v1.3.4/atom/common/api/atom_api_key_weak_map.h)
|
||||
|
||||
[window-disappearing]: https://electronjs.org/docs/faq/#my-apps-windowtray-disappeared-after-a-few-minutes
|
||||
[WeakMap]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap
|
||||
[remote-procedure-call]: https://en.wikipedia.org/wiki/Remote_procedure_call
|
||||
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
title: Electron joins the OpenJS Foundation
|
||||
author:
|
||||
- felixrieseberg
|
||||
date: '2019-12-11'
|
||||
---
|
||||
|
||||
At [Node+JS Interactive](https://events19.linuxfoundation.org/events/nodejs-interactive-2019/) in Montreal, the [OpenJS Foundation](https://openjsf.org/) announced that it accepted Electron into the Foundation's incubation program. The Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large.
|
||||
|
||||
The OpenJS Foundation is host to a number of open source JavaScript projects including jQuery, Node.js, and webpack. It's supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. Electron is an open–source framework for building cross-platform desktop applications with web technologies.
|
||||
|
||||
This is an exciting move for Electron, and we see it as a next step in our evolution as an open-source project.
|
||||
|
||||
---
|
||||
|
||||
## What this means for developers
|
||||
|
||||
Electron joining the OpenJS Foundation does not change how Electron is made, released, or used — and does not directly affect developers building applications with Electron. Even though Electron was originally created at GitHub in 2013, it is currently maintained by a number of organizations and individuals. In 2019, Electron codified its governance structure and invested heavily into formalizing how decisions affecting the entire project are made. We believe that having multiple organizations and developers investing in and collaborating on Electron makes the project stronger.
|
||||
|
||||
Lifting Electron up from being owned by a single corporate entity and moving it into a neutral foundation focused on supporting the web and JavaScript ecosystem is a natural next step as we mature as an open-source project.
|
||||
|
||||
## Learning more
|
||||
|
||||
You can read up on the foundation, its mission, and its members on the [OpenJSF website](https://www.notion.so/Electron-joins-the-OpenJS-Foundation-d898f12480874e56abe78f29b041fb91#0801fd7e9fa340afbcdce0510ba05f8a). For more information and quotes about the acceptance of Electron into the OpenJSF incubation program, check out the official press release. To learn more about the humans behind Electron and how they work together, take a look at our [Governance page](https://electronjs.org/governance).
|
||||
|
||||
To get started with Electron itself, take a peek at [our documentation](https://electronjs.org/docs).
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
title: Electron Meetup at GitHub HQ
|
||||
author: jlord
|
||||
date: '2015-09-17'
|
||||
---
|
||||
|
||||
Join us September 29th at GitHub's HQ for an Electron meetup hosted by Atom team members [@jlord](https://github.com/jlord) and [@kevinsawicki](https://github.com/kevinsawicki). There will be talks, food to snack on, and time to hangout and meet others doing cool things with Electron. We'll also have a bit of time to do lightning talks for those interested. Hope to see you there!
|
||||
|
||||
---
|
||||
|
||||
**Talks**
|
||||
|
||||
- **Jonathan Ross** and **Francois Laberge** from [Jibo](http://jibo.com) will share how they use Electron to animate a robot.
|
||||
- **Jessica Lord** will talk about building a teaching tool, [Git-it](https://github.com/jlord/git-it-electron), on Electron.
|
||||
- **Tom Moor** will talk about the pros and cons of building video and screen sharing on Electron with [speak.io](https://speak.io).
|
||||
- **Ben Gotow** will preview N1: [The Nylas Mail Client](https://www.nylas.com/blog/splitting-the-atom) and talk about developing it on Electron.
|
||||
|
||||
### Details
|
||||
|
||||
- **Location:** GitHub HQ, 275 Brannan Street, San Francisco, CA, 94107
|
||||
- **Date:** Tuesday, September 29th, 2015
|
||||
- **Time:** 6pm - 9pm
|
||||
- **RSVP:** [ti.to/github-events/electron-meetup](https://ti.to/github-events/electron-meetup)
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
title: Electron becomes an OpenJS Foundation Impact Project
|
||||
author:
|
||||
- VerteDinde
|
||||
date: '2020-06-23'
|
||||
---
|
||||
|
||||
At [OpenJS World](https://events.linuxfoundation.org/openjs-world/) this morning, we announced that Electron has officially graduated from the [OpenJS Foundation's](https://openjsf.org/) incubation program, and is now an OpenJS Foundation Impact Project.
|
||||
|
||||
Electron [entered incubation in December of 2019](https://openjsf.org/blog/2019/12/11/electron-joins-the-openjs-foundation/), at the last OpenJS Foundation global conference in Montreal. We're excited to take a larger role in the JavaScript community as an Impact Project, and continue our partnership with the OpenJS Foundation.
|
||||
|
||||
---
|
||||
|
||||
## Learning more
|
||||
|
||||
You can read up on the foundation, its mission, and its members on the [OpenJSF website](https://www.notion.so/Electron-joins-the-OpenJS-Foundation-d898f12480874e56abe78f29b041fb91#0801fd7e9fa340afbcdce0510ba05f8a). The OpenJS Foundation is host to a number of open source JavaScript projects including jQuery, Node.js, and webpack. It's supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft.
|
||||
|
||||
Electron is an open–source framework for building cross-platform desktop applications with web technologies. To learn more about the humans behind Electron and how they work together, take a look at our [Governance page](https://electronjs.org/governance).
|
||||
|
||||
To get started with Electron itself, take a peek at [our documentation](https://electronjs.org/docs).
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
---
|
||||
title: Electron Podcasts
|
||||
author: jlord
|
||||
date: '2016-07-26'
|
||||
---
|
||||
|
||||
Looking for an introduction to Electron? Two new podcasts have just been released that give a great overview of what it is, why it was built, and how it is being used.
|
||||
|
||||
---
|
||||
|
||||
**Out now:**
|
||||
|
||||
<a href="http://hanselminutes.com/534/creating-cross-platform-electron-apps-with-jessica-lord"><img src="https://cloud.githubusercontent.com/assets/2289/23483197/d14f716e-fe86-11e6-95da-dcfe73bb86f7.jpg" width="200"/></a>
|
||||
|
||||
### [Hanselminutes: Creating cross-platform Electron apps](http://hanselminutes.com/534/creating-cross-platform-electron-apps-with-jessica-lord)
|
||||
|
||||
> Is Electron "just Chrome in a frame" or is it so much more? Jessica sets Scott on the right path and explains exactly where the Electron platform fits into your development world.
|
||||
|
||||
<br/>
|
||||
|
||||
<a href="https://javascriptair.com/episodes/2016-07-06"><img src="https://raw.githubusercontent.com/javascriptair/site/master/resources/logo.png" width="200"/></a>
|
||||
|
||||
### [JavaScript Air: Electron Apps](https://javascriptair.com/episodes/2016-07-06)
|
||||
|
||||
> Electron is becoming more and more of a relevant and popular way of building multi-platform desktop apps with web technologies. Let's get a dive into this awesome tech and see how we can use it to enhance our own experience and our user's experience on the desktop.
|
||||
|
||||
<br/>
|
||||
|
||||
If you're looking for an introduction to Electron, give the first a listen. The second goes into more detail about building apps with great tips from Nylas's [Evan Morikawa](https://twitter.com/E0M).
|
||||
|
||||
We are currently working on two more podcasts that should come out next month, keep an eye on the [@ElectronJS](https://twitter.com/ElectronJS) Twitter account for updates.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
title: Mac App Store and Windows Auto Updater on Electron
|
||||
author: jlord
|
||||
date: '2015-11-05'
|
||||
---
|
||||
|
||||
Recently Electron added two exciting features: a Mac App Store compatible build and a built-in Windows auto updater.
|
||||
|
||||
---
|
||||
|
||||
## Mac App Store Support
|
||||
|
||||
<img src='https://cloud.githubusercontent.com/assets/1305617/10928574/a301640c-825e-11e5-918e-a06b7a55dcb4.png' width="300"/>
|
||||
|
||||
As of `v0.34.0` each Electron release includes a build compatible with the Mac App Store. Previously an application built on Electron would not comply with Apple's requirements for the Mac App Store. Most of these requirements are related to the use of private APIs. In order to sandbox Electron in such a way that it complies with the requirements two modules needed to be removed:
|
||||
|
||||
- `crash-reporter`
|
||||
- `auto-updater`
|
||||
|
||||
Additionally some behaviors have changed with respect to detecting DNS changes, video capture and accessibility features. You can read more about the changes and [submitting your app to the Mac App store](https://electronjs.org/docs/latest/tutorial/mac-app-store-submission-guide) in the documentation. The distributions can be found on the [Electron releases page](https://github.com/electron/electron/releases), prefixed with `mas-`.
|
||||
|
||||
Related Pull Requests: [electron/electron#3108](https://github.com/electron/electron/pull/3108), [electron/electron#2920](https://github.com/electron/electron/pull/2920)
|
||||
|
||||
## Windows Auto Updater
|
||||
|
||||
In Electron `v0.34.1` the `auto-updater` module was improved in order to work with [`Squirrel.Windows`](https://github.com/Squirrel/Squirrel.Windows). This means that Electron ships with easy ways for auto updating your app on both OS X and Windows. You can read more on [setting up your app for auto updating on Windows](https://github.com/electron/electron/blob/master/docs/api/auto-updater.md#windows) in the documentation.
|
||||
|
||||
Related Pull Request: [electron/electron#1984](https://github.com/electron/electron/pull/1984)
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
title: Atom Shell is now Electron
|
||||
author: kevinsawicki
|
||||
date: '2015-04-23'
|
||||
---
|
||||
|
||||
Atom Shell is now called Electron. You can learn more about Electron and what people are building with it at its new home [electronjs.org][electron].
|
||||
|
||||
---
|
||||
|
||||
[][electron]
|
||||
|
||||
Electron is the cross-platform application shell we originally built for the [Atom editor][atom] to handle the Chromium/Node.js event loop integration and native APIs.
|
||||
|
||||
When we got started, our goal wasn't just to support the needs of a text editor. We also wanted to create a straightforward framework that would allow people to use web technologies to build cross-platform desktop apps with all of the native trimmings.
|
||||
|
||||
In two years, Electron has grown immensely. It now includes automatic app updates, Windows installers, crash reporting, notifications, and other useful native app features — all exposed through JavaScript APIs. And we have more in the works. We plan to extract even more libraries from Atom to make building a native app with web technologies as easy as possible.
|
||||
|
||||
So far, individual developers, early-stage startups, and large companies have built apps on Electron. They've created a huge range of apps — including chat apps, database explorers, map designers, collaborative design tools, and mobile prototyping apps.
|
||||
|
||||
Check out the new [electronjs.org][electron] to see more of the apps people have built on Electron or take a look at the [docs][docs] to learn more about what else you can make.
|
||||
|
||||
If you've already gotten started, we'd love to chat with you about the apps you're building on Electron. Email [info@electronjs.org](mailto:info@electronjs.org?Subject=Electron) to tell us more. You can also follow the new [@ElectronJS](https://twitter.com/electronjs) Twitter account to stay connected with the project.
|
||||
|
||||
:zap: :blue_heart: :electric_plug:
|
||||
|
||||
[atom]: https://atom.io
|
||||
[docs]: https://github.com/electron/electron/tree/master/docs#readme
|
||||
[electron]: https://electronjs.org
|
||||
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
---
|
||||
title: Chromium FileReader Vulnerability Fix
|
||||
author: marshallofsound
|
||||
date: '2019-03-07'
|
||||
---
|
||||
|
||||
A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.
|
||||
|
||||
This vulnerability has been assigned `CVE-2019-5786`. You can read more about it in the [Chrome Blog Post](https://chromereleases.googleblog.com/2019/03/stable-channel-update-for-desktop.html).
|
||||
|
||||
Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron ASAP.
|
||||
|
||||
---
|
||||
|
||||
## Scope
|
||||
|
||||
This affects any Electron application that may run third-party or untrusted JavaScript.
|
||||
|
||||
## Mitigation
|
||||
|
||||
Affected apps should upgrade to a patched version of Electron.
|
||||
|
||||
We've published new versions of Electron which include fixes for this vulnerability:
|
||||
* [4.0.8](https://github.com/electron/electron/releases/tag/v4.0.8)
|
||||
* [3.1.6](https://github.com/electron/electron/releases/tag/v3.1.6)
|
||||
* [3.0.16](https://github.com/electron/electron/releases/tag/v3.0.16)
|
||||
* [2.0.18](https://github.com/electron/electron/releases/tag/v2.0.18)
|
||||
|
||||
The latest beta of Electron 5 was tracking Chromium 73 and therefore is already patched:
|
||||
* [5.0.0-beta.5](https://github.com/electron/electron/releases/tag/v5.0.0-beta.5)
|
||||
|
||||
## Further Information
|
||||
|
||||
This vulnerability was discovered by Clement Lecigne of Google's Threat Analysis Group and reported to the Chrome team. The Chrome blog post can be found [here](https://chromereleases.googleblog.com/2019/03/stable-channel-update-for-desktop.html).
|
||||
|
||||
To learn more about best practices for keeping your Electron apps secure, see our [security tutorial].
|
||||
|
||||
If you wish to report a vulnerability in Electron, email security@electronjs.org.
|
||||
|
||||
[security tutorial]: https://electronjs.org/docs/tutorial/security
|
||||
|
|
@ -1,106 +0,0 @@
|
|||
---
|
||||
title: From native to JavaScript in Electron
|
||||
author: codebytere
|
||||
date: '2019-03-19'
|
||||
---
|
||||
|
||||
How do Electron's features written in C++ or Objective-C get to JavaScript so they're available to an end-user?
|
||||
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
[Electron](https://electronjs.org) is a JavaScript platform whose primary purpose is to lower the barrier to entry for developers to build robust desktop apps without worrying about platform-specific implementations. However, at its core, Electron itself still needs platform-specific functionality to be written in a given system language.
|
||||
|
||||
In reality, Electron handles the native code for you so that you can focus on a single JavaScript API.
|
||||
|
||||
How does that work, though? How do Electron's features written in C++ or Objective-C get to JavaScript so they're available to an end-user?
|
||||
|
||||
To trace this pathway, let's start with the [`app` module](https://electronjs.org/docs/api/app).
|
||||
|
||||
By opening the [`app.ts`](https://github.com/electron/electron/blob/0431997c8d64c9ed437b293e8fa15a96fc73a2a7/lib/browser/api/app.ts) file inside our `lib/` directory, you'll find the following line of code towards the top:
|
||||
|
||||
```js
|
||||
const binding = process.electronBinding('app')
|
||||
```
|
||||
|
||||
This line points directly to Electron's mechanism for binding its C++/Objective-C modules to JavaScript for use by developers. This function is created by the header and [implementation file](https://github.com/electron/electron/blob/0431997c8d64c9ed437b293e8fa15a96fc73a2a7/atom/common/api/electron_bindings.cc) for the `ElectronBindings` class.
|
||||
|
||||
## `process.electronBinding`
|
||||
|
||||
These files add the `process.electronBinding` function, which behaves like Node.js’ `process.binding`. `process.binding` is a lower-level implementation of Node.js' [`require()`](https://nodejs.org/api/modules.html#modules_require_id) method, except it allows users to `require` native code instead of other code written in JS. This custom `process.electronBinding` function confers the ability to load native code from Electron.
|
||||
|
||||
When a top-level JavaScript module (like `app`) requires this native code, how is the state of that native code determined and set? Where are the methods exposed up to JavaScript? What about the properties?
|
||||
|
||||
## `native_mate`
|
||||
|
||||
At present, answers to this question can be found in `native_mate`: a fork of Chromium's [`gin` library](https://chromium.googlesource.com/chromium/src.git/+/lkgr/gin/) that makes it easier to marshal types between C++ and JavaScript.
|
||||
|
||||
Inside `native_mate/native_mate` there's a header and implementation file for `object_template_builder`. This is what allow us to form modules in native code whose shape conforms to what JavaScript developers would expect.
|
||||
|
||||
### `mate::ObjectTemplateBuilder`
|
||||
|
||||
If we look at every Electron module as an `object`, it becomes easier to see why we would want to use `object_template_builder` to construct them. This class is built on top of a class exposed by V8, which is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. V8 implements the JavaScript (ECMAScript) specification, so its native functionality implementations can be directly correlated to implementations in JavaScript. For example, [`v8::ObjectTemplate`](https://v8docs.nodesource.com/node-0.8/db/d5f/classv8_1_1_object_template.html) gives us JavaScript objects without a dedicated constructor function and prototype. It uses `Object[.prototype]`, and in JavaScript would be equivalent to [`Object.create()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create).
|
||||
|
||||
To see this in action, look to the implementation file for the app module, [`atom_api_app.cc`](https://github.com/electron/electron/blob/0431997c8d64c9ed437b293e8fa15a96fc73a2a7/atom/browser/api/atom_api_app.cc). At the bottom is the following:
|
||||
|
||||
```cpp
|
||||
mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
|
||||
.SetMethod("getGPUInfo", &App::GetGPUInfo)
|
||||
```
|
||||
|
||||
In the above line, `.SetMethod` is called on `mate::ObjectTemplateBuilder`. `.SetMethod` can be called on any instance of the `ObjectTemplateBuilder` class to set methods on the [Object prototype](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/prototype) in JavaScript, with the following syntax:
|
||||
|
||||
```cpp
|
||||
.SetMethod("method_name", &function_to_bind)
|
||||
```
|
||||
|
||||
This is the JavaScript equivalent of:
|
||||
|
||||
```js
|
||||
function App{}
|
||||
App.prototype.getGPUInfo = function () {
|
||||
// implementation here
|
||||
}
|
||||
```
|
||||
|
||||
This class also contains functions to set properties on a module:
|
||||
|
||||
```cpp
|
||||
.SetProperty("property_name", &getter_function_to_bind)
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```cpp
|
||||
.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)
|
||||
```
|
||||
|
||||
These would in turn be the JavaScript implementations of [Object.defineProperty](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty):
|
||||
|
||||
```js
|
||||
function App {}
|
||||
Object.defineProperty(App.prototype, 'myProperty', {
|
||||
get() {
|
||||
return _myProperty
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
and
|
||||
|
||||
```js
|
||||
function App {}
|
||||
Object.defineProperty(App.prototype, 'myProperty', {
|
||||
get() {
|
||||
return _myProperty
|
||||
}
|
||||
set(newPropertyValue) {
|
||||
_myProperty = newPropertyValue
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
It’s possible to create JavaScript objects formed with prototypes and properties as developers expect them, and more clearly reason about functions and properties implemented at this lower system level!
|
||||
|
||||
The decision around where to implement any given module method is itself a complex and oft-nondeterministic one, which we'll cover in a future post.
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
---
|
||||
title: 'Project of the Week: Ghost'
|
||||
author:
|
||||
- felixrieseberg
|
||||
- zeke
|
||||
date: '2017-02-14'
|
||||
---
|
||||
|
||||
This week we chatted with [Felix Rieseberg](https://felixrieseberg.com/), desktop engineer at [Slack](https://slack.com/) and maintainer of [Ghost Desktop](https://ghost.org/downloads/), an Electron client for the [Ghost](https://ghost.org/) publishing platform.
|
||||
|
||||
---
|
||||
|
||||
<div class="pt-5">
|
||||
<img src="https://cloud.githubusercontent.com/assets/2289/22913898/7396b0de-f222-11e6-8e5d-147a7ced37a9.png" alt="Ghost Desktop Screenshot"/>
|
||||
</div>
|
||||
|
||||
## What is Ghost?
|
||||
|
||||
Ghost is a fully open source, hackable platform for building and running a modern online publication. We power blogs, magazines and journalists from Zappos to Sky News.
|
||||
|
||||
## What makes it different from other publishing platforms?
|
||||
|
||||
Ghost was founded in April 2013, after a very successful Kickstarter campaign to create a new platform focused solely on professional publishing. Our mission is to create the best open source tools for independent journalists and writers across the world, and have a real impact on the future of online media. It offers a simpler, more focussed experience: Our editor is designed solely around providing the best possible writing experience.
|
||||
|
||||
Compared to the all-time classic WordPress, it offers a simpler, more streamlined experience - it is easier to setup and maintain, comes with all important features out-of-the-box, and is dramatically faster. Compared to other online platforms, Ghost gives writers full ownership and control over their content, allows full customization, and enables authors to build a business around their publication.
|
||||
|
||||
## Is Ghost a for-profit company?
|
||||
|
||||
This one is important to us: Ghost is an independent non-profit organisation. We build publishing tools for modern journalism & blogging because we believe freedom of speech is important. Our software is released under a [free open source license](https://github.com/TryGhost/Ghost), our business model is [completely transparent](https://blog.ghost.org/year-3/), and our legal structure means that 100% of the money we make is reinvested into making Ghost better.
|
||||
|
||||
## What is Ghost Desktop?
|
||||
|
||||
Ghost Desktop allows writers to manage multiple blogs at once - and to focus on their writing. Simple things like common writing shortcuts can't be realized in a browser, but are available in our desktop app. It allows other applications to communicate directly [with the blog via deeplinks](https://github.com/tryghost/ghost-desktop/blob/master/docs/deeplinks.md).
|
||||
|
||||
## What is Ghost for Journalism?
|
||||
|
||||
This year we're very excited to be dedicating our entire 10 person full-time Ghost team to helping grow three independent publications, along with $45,000 in resources toward their efforts. We're calling it [Ghost for Journalism](https://ghost.org/journalism/).
|
||||
|
||||
We've been building Ghost as the web's next great platform for independent publishers for about three and half years now, and we've now reached a really interesting inflection point. We started this journey to create a simple, well designed blogging platform which could be used by just about anyone. That was always going to be step one.
|
||||
|
||||
Long term, we want Ghost to be an incredible platform for the world's best journalism, and that means we need to build features to attract exactly those people. This year we're making a very conscious decision to focus on just that.
|
||||
|
||||
## Why did you choose to build Ghost Desktop on Electron?
|
||||
|
||||
Ghost uses JavaScript and Node.js on both the backend and frontend, so being able to utilize the same technology and skillset enables our team to move faster, build more, and ultimately deliver a better experience. In addition, being able to share more than 95% of code between the macOS, Windows, and Linux version of the app allows us to focus on building a great core user experience, without having to maintain one code base for each platform.
|
||||
|
||||
## What are some challenges you've faced while building Ghost Desktop?
|
||||
|
||||
Spellchecking is likely still one of the most difficult services offered - we could easily utilize one of the many online services, but correctly spellchecking text in multiple languages while guarding the privacy and autonomy of our users is not an easy task.
|
||||
|
||||
## In what areas should Electron be improved?
|
||||
|
||||
We would love to see Electron bring the operating system's native spellchecking capabilities to their apps. We're dreaming about a world in which an `<input>` field receives the same services as a `NSTextView`, but we are also intimately aware how difficult that is.
|
||||
|
||||
## What are your favorite things about Electron?
|
||||
|
||||
JavaScript is famous for being a vast ecosystem, involving countless tools and frameworks - but the convenience it affords us is hard to overstate. Building an app with Electron is only _slightly_ harder than building a web app, which is an amazing feat.
|
||||
|
||||
## Is Ghost done? If not, what's coming next?
|
||||
|
||||
Ghost Desktop is also an ongoing project - we're pretty far from being done. We have been talking for a while about bringing a full offline mode to our users, and we're getting fairly close. Other notable work areas are the extension and integration with other text editing apps (like Word or Atom), ultimately allowing people to write posts using their favorite tools. In general, once we've shipped the offline mode feature, we're looking for deeper integration with the operating system. If that sounds interesting to you, [join us](https://github.com/tryghost/ghost-desktop)!
|
||||
|
||||
## What are some of your favorite Electron apps?
|
||||
|
||||
I'm a big fan of [Kap](https://getkap.co/), [Felony](https://github.com/henryboldi/felony), and [Visual Studio Code](https://code.visualstudio.com).
|
||||
|
||||
👻
|
||||
43
blog/gn.md
43
blog/gn.md
|
|
@ -1,43 +0,0 @@
|
|||
---
|
||||
title: "Using GN to Build Electron"
|
||||
author: nornagon
|
||||
date: '2018-09-05'
|
||||
---
|
||||
|
||||
Electron now uses GN to build itself. Here's a discussion of why.
|
||||
|
||||
---
|
||||
|
||||
# GYP and GN
|
||||
|
||||
When Electron was first released in 2013, Chromium's build configuration was written with [GYP], short for "Generate Your Projects".
|
||||
|
||||
In 2014, the Chromium project introduced a new build configuration tool called [GN] (short for "Generate [Ninja]") Chromium's build files were migrated to GN and GYP was removed from the source code.
|
||||
|
||||
Electron has historically kept a separation between the main [Electron code] and [libchromiumcontent], the part of Electron that wraps Chromium's 'content' submodule. Electron has carried on using GYP, while libchromiumcontent -- as a subset of Chromium -- switched to GN when Chromium did.
|
||||
|
||||
Like gears that don't quite mesh, there was friction between using the two build systems. Maintaining compatibility was error-prone, from compiler flags and `#defines` that needed to be meticulously kept in sync between Chromium, Node, V8, and Electron.
|
||||
|
||||
To address this, the Electron team has been working on moving everything to GN. Today, the [commit](https://github.com/electron/electron/pull/14097) to remove the last of the GYP code from Electron was landed in master.
|
||||
|
||||
# What this means for you
|
||||
|
||||
If you're contributing to Electron itself, the process of checking out and building Electron from `master` or 4.0.0 is very different than it was in 3.0.0 and earlier. See the [GN build instructions](https://github.com/electron/electron/blob/master/docs/development/build-instructions-gn.md) for details.
|
||||
|
||||
If you're developing an app with Electron, there are a few minor changes you might notice in the new Electron 4.0.0-nightly; but more than likely, Electron's change in build system will be totally transparent to you.
|
||||
|
||||
# What this means for Electron
|
||||
|
||||
GN is [faster](https://chromium.googlesource.com/chromium/src/tools/gn/+/48062805e19b4697c5fbd926dc649c78b6aaa138/README.md) than GYP and its files are more readable and maintainable. Moreover, we hope that using a single build configuration system will reduce the work required to upgrade Electron to new versions of Chromium.
|
||||
|
||||
* It's already helped development on Electron 4.0.0 substantially because Chromium 67 removed support for MSVC and switched to building with Clang on Windows. With the GN build, we inherit all the compiler commands from Chromium directly, so we got the Clang build on Windows for free!
|
||||
|
||||
* It's also made it easier for Electron to use [BoringSSL] in a unified build across Electron, Chromium, and Node -- something that was [problematic before](https://electronjs.org/blog/electron-internals-using-node-as-a-library#shared-library-or-static-library).
|
||||
|
||||
|
||||
[BoringSSL]: https://boringssl.googlesource.com/boringssl/
|
||||
[Electron code]: https://github.com/electron/electron
|
||||
[GN]: https://gn.googlesource.com/gn/
|
||||
[GYP]: https://gyp.gsrc.io/
|
||||
[Ninja]: https://ninja-build.org/
|
||||
[libchromiumcontent]: https://github.com/electron/libchromiumcontent
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
---
|
||||
title: Electron Governance
|
||||
author:
|
||||
- ckerr
|
||||
- sofianguy
|
||||
date: '2019-03-18'
|
||||
---
|
||||
|
||||
As Electron grows in popularity for desktop applications, the team working on it has also grown: we have more fulltime maintainers who work for different companies, live in different timezones, and have different interests. We're introducing a governance structure so we can keep growing smoothly.
|
||||
|
||||
---
|
||||
|
||||
## Why are things changing?
|
||||
|
||||
People in the Electron project coordinate in timezones around the world with volunteers, with full-time maintainers, and with several companies who all rely on Electron. Until now, we've been successful with informal coordination; but as the team has grown, we've found that the approach doesn't scale. We also want to make it easier for new contributors to find a place to call home in the project.
|
||||
|
||||
## Working Groups
|
||||
|
||||
Electron governance includes working groups that are responsible for different parts of the project. We're starting out with seven groups:
|
||||
* Community & Safety: Handles [Code of Conduct](https://github.com/electron/governance/blob/master/CODE_OF_CONDUCT.md) issues.
|
||||
* Docs & Tooling: Oversees externally-focused tooling (e.g. [Fiddle](https://electronjs.org/fiddle), [Forge](https://electronforge.io/)) and the Electron [documentation](https://electronjs.org/docs).
|
||||
* Outreach: Helps grow the Electron community.
|
||||
* Releases: Ensures releases are stable and on schedule.
|
||||
* Security: Performs security testing and responds to security issues.
|
||||
* Upgrades: Integrates upstream upgrades, such as new versions of V8, Chromium, and Node.
|
||||
* Website: Maintains and improves [the Electron website](https://electronjs.org/).
|
||||
|
||||
These groups will coordinate with each other, but each has their own meeting schedules and agendas to be productive on their own. More details on these groups are available at the [governance repository](https://github.com/electron/governance/blob/master/README.md).
|
||||
|
||||
## Does this change the Electron project's direction?
|
||||
|
||||
This shouldn't have any direct effect on Electron's direction. If our strategy is successful, working groups will make it easier for new contributors to find topics that interest them, and make maintainers' lives simpler by moving discussion unrelated to their day-to-day work to other groups. If that happens, it may indirectly affect things by having more unblocked people working together.
|
||||
|
||||
## Where can I learn more?
|
||||
|
||||
* The governance [repo](https://github.com/electron/governance/) and [charter](https://github.com/electron/governance/tree/master/charter) have information about the new governance structure.
|
||||
* Each working group has its own page: [Community](https://github.com/electron/governance/tree/master/wg-community-safety), [Docs & Tools](https://github.com/electron/governance/tree/master/wg-docs-tools), [Outreach](https://github.com/electron/governance/tree/master/wg-outreach), [Releases](https://github.com/electron/governance/tree/master/wg-releases), [Security](https://github.com/electron/governance/tree/master/wg-security), [Upgrades](https://github.com/electron/governance/tree/master/wg-upgrades), and [Website](https://github.com/electron/governance/tree/master/wg-website).
|
||||
* You can contact the maintainers by [opening an issue](https://github.com/electron/governance/issues) or mailing us at [info@electronjs.org](mailto:info@electronjs.org).
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
---
|
||||
title: "Internationalization Updates"
|
||||
author: vanessayuenn
|
||||
date: '2018-06-20'
|
||||
---
|
||||
|
||||
Ever since the [launch](https://electronjs.org/blog/new-website) of the new internationalized Electron website, we have been working hard to make the Electron development experience even more accessible to developers outside of the English speaking world.
|
||||
|
||||
So here we are with some exciting i18n updates!
|
||||
|
||||
---
|
||||
|
||||
## 🌐 Language Toggle
|
||||
|
||||
Did you know that many people who read translated documentation often cross reference that with the original English documentation? They do this to familiarize themselves with English docs, and to avoid outdated or inaccurate translations, which is one caveat of internationalized documentations.
|
||||
|
||||
<figure>
|
||||
<img class="screenshot" src="https://user-images.githubusercontent.com/6842965/35578586-cae629e2-05e4-11e8-9431-0278f8c2b39f.gif" alt="Language toggle on Electron documentation"/>
|
||||
</figure>
|
||||
|
||||
To make cross-referencing to English docs easier, we recently shipped a feature that allows you to seamlessly toggle a section of the Electron documentation between English and whatever language you're viewing the website in. The language toggle will show up as long as you have a non-English locale selected on the website.
|
||||
|
||||
## ⚡️ Quick Access to Translation Page
|
||||
|
||||
<figure>
|
||||
<img class="screenshot" src="https://user-images.githubusercontent.com/6842965/36511386-c32e31fc-1766-11e8-8484-7466be6a5eb0.png" alt="New Electron documentation footer in Japanese"/>
|
||||
<figcaption>Electron documentation footer in Japanese</figcaption>
|
||||
</figure>
|
||||
|
||||
Notice a typo or an incorrect translation while you're reading the documentation? You no longer have to log in to Crowdin, pick your locale, find the file you'd like the fix, etc etc. Instead, you can just scroll down to the bottom of the said doc, and click "Translate this doc" (or the equivalent in your language). Voila! You are brought straight to the Crowdin translation page. Now apply your translation magic!
|
||||
|
||||
## 📈 Some Statistics
|
||||
|
||||
Ever since we have publicized the Electron documentation i18n effort, we have seen _huge_ growth in translation contributions from Electron community members from all around the world. To date, we have **1,719,029 strings translated, from 1,066 community translators, and in 25 languages**.
|
||||
|
||||
<figure>
|
||||
<a href="https://crowdin.com/project/electron/">
|
||||
<img class="screenshot" src="https://user-images.githubusercontent.com/6842965/41649826-ca26037c-747c-11e8-9594-5ce12d2978e2.png" alt="Translation Forecast provided by Crowdin"/>
|
||||
<figcaption>Translation Forecast provided by Crowdin</figcaption>
|
||||
</a>
|
||||
</figure>
|
||||
|
||||
Here is a fun graph showing the approximate amount of time needed to translate the project into each language if the existing tempo (based on the project activity during the last 14 days at the time of writing) is preserved.
|
||||
|
||||
## 📃 Translator Survey
|
||||
|
||||
We would like to give a huge ❤️ thank you ❤️ to everyone who has contributed their time to help improving Electron! In order to properly acknowledge the hard work of our translator community, we have created a survey to collect some information (namely the mapping between their Crowdin and Github usernames) about our translators.
|
||||
|
||||
If you are one of our incredible translators, please take a few minutes to fill this out: https://goo.gl/forms/b46sjdcHmlpV0GKT2.
|
||||
|
||||
## 🙌 Node's Internationalization Effort
|
||||
|
||||
Because of the success of Electron's i18n initiative, Node.js decided to model [their revamped i18n effort](https://github.com/nodejs/i18n) after the pattern we use as well! 🎉 The [Node.js i18n initiative](https://github.com/nodejs/i18n) has now been launched and gained great momentum, but you can stil read about the early proposal and reasoning behind it [here](https://medium.com/the-node-js-collection/internationalizing-node-js-fe7761798b0a).
|
||||
|
||||
## 🔦 Contributing Guide
|
||||
|
||||
If you're interested in joining our effort to make Electron more international friendly, we have a handy-dandy [contributing guide](https://github.com/electron/i18n/blob/master/contributing.md) to help you get started. Happy internationalizing! 📚
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
---
|
||||
title: "New in Electron 2: In-App Purchases"
|
||||
author: zeke
|
||||
date: '2018-04-04'
|
||||
---
|
||||
|
||||
The new Electron 2.0 release line is [packed](https://github.com/electron/electron/releases/tag/v2.0.0-beta.1) with new features and fixes. One of the highlights from this new major version is a new
|
||||
[`inAppPurchase` API](https://github.com/electron/electron/blob/master/docs/api/in-app-purchase.md)
|
||||
for Apple's [Mac App Store](https://support.apple.com/en-us/HT202023).
|
||||
|
||||
---
|
||||
|
||||
In-app purchases enable content or subscriptions to be purchased directly
|
||||
from within apps. This gives developers an easy way to embrace the
|
||||
[freemium business model](https://developer.apple.com/app-store/freemium-business-model/),
|
||||
wherein users pay nothing to download an app and are offered optional
|
||||
in-app purchases for premium features, additional content, or subscriptions.
|
||||
|
||||
The new API was added to Electron by community contributor
|
||||
[Adrien Fery](https://github.com/AdrienFery) to enable in-app purchases in
|
||||
[Amanote](https://amanote.com/), a note-taking Electron app for lectures and
|
||||
conferences. Amanote is free to download and allows clear and structured notes
|
||||
to be added to PDFs, with features like mathematical formulae, drawings, audio
|
||||
recording, and more.
|
||||
|
||||
Since adding in-app purchase support to the Mac version of Amanote, Adrien
|
||||
has noted a **40% increase in sales**!
|
||||
|
||||
## Getting Started
|
||||
|
||||
The new [`inAppPurchase`](https://github.com/electron/electron/blob/master/docs/api/in-app-purchase.md) API has already landed in the latest Electron beta:
|
||||
|
||||
```sh
|
||||
npm i -D electron@beta
|
||||
```
|
||||
|
||||
The docs for the API can be [found on GitHub](https://github.com/electron/electron/blob/master/docs/api/in-app-purchase.md),
|
||||
and Adrien has been kind enough to write a tutorial on how to use the API. To
|
||||
get started adding in-app purchases to your app, [see the tutorial](https://github.com/AdrienFery/electron/blob/a69bbe882aed1a5aee2b7910afe09900275b2bf6/docs/tutorial/in-app-purchases.md).
|
||||
|
||||
More [improvements to the API](https://github.com/electron/electron/pull/12464)
|
||||
are in the works, and will soon be landing in an upcoming Electron beta release.
|
||||
|
||||
## Windows Could Be Next
|
||||
|
||||
Up next, Adrien is hoping to open a new revenue channel for Amanote by adding
|
||||
support for Microsoft Store in-app purchases in Electron. Stay tuned for
|
||||
developments on that!
|
||||
152
blog/jasper.md
152
blog/jasper.md
|
|
@ -1,152 +0,0 @@
|
|||
---
|
||||
title: 'Project of the Week: Jasper'
|
||||
author:
|
||||
- h13i32maru
|
||||
- watilde
|
||||
- zeke
|
||||
date: '2017-03-21'
|
||||
---
|
||||
|
||||
This week we interviewed the creator of [Jasper], an Electron-based tool for
|
||||
managing GitHub notifications.
|
||||
|
||||
---
|
||||
|
||||
## Hello! Who are you?
|
||||
|
||||
I'm [Ryo Maruyama](https://github.com/h13i32maru), a software developer in Japan. I am developing [Jasper](https://jasperapp.io) and [ESDoc](https://esdoc.org).
|
||||
|
||||
## What is Jasper?
|
||||
|
||||
[Jasper] is a flexible and powerful issue reader for GitHub. It supports issues and pull requests on github.com and GitHub Enterprise.
|
||||
|
||||
[](https://jasperapp.io/)
|
||||
|
||||
## Why did you make it?
|
||||
|
||||
When people use GitHub in their job or OSS activities, they tend to receive many notifications on a daily basis. As a way to subscribe to the notifications, GitHub provides email and [web notifications](https://github.com/notifications). I used these for a couple of years, but I faced the following problems:
|
||||
|
||||
- It's easy to overlook issues where I was mentioned, I commented, or I am watching.
|
||||
- I put some issues in a corner of my head to check later, but I sometimes forget about them.
|
||||
- To not forget issues, I keep many tabs open in my browser.
|
||||
- It's hard to check all issues that are related to me.
|
||||
- It's hard to grasp all of my team's activity.
|
||||
|
||||
I was spending a lot of time and energy trying to prevent those problems, so I decided to make an issue reader for GitHub to solve these problems efficiently, and started developing Jasper.
|
||||
|
||||
## Who's using Jasper?
|
||||
|
||||
Jasper is used by developers, designers, and managers in several companies that are using GitHub.
|
||||
Of course, some OSS developers also are using it.
|
||||
And it is also used by some people at GitHub!
|
||||
|
||||
<a href="https://twitter.com/mistydemeo/status/778841101109080064"><img src="https://cloud.githubusercontent.com/assets/2289/24108650/75f87706-0d4b-11e7-8fcb-9fbedf2f66ea.png" width="500"/></a>
|
||||
|
||||
<a href="https://twitter.com/jna_sh/status/798283937344651264"><img src="https://cloud.githubusercontent.com/assets/2289/24108649/75f4b9e0-0d4b-11e7-9701-24a0ef251ad2.png" width="500"/></a>
|
||||
|
||||
## How does Jasper work?
|
||||
|
||||
Once Jasper is configured, the following screen appears. From left to right, you can see "streams list", "issues list" and "issue body".
|
||||
|
||||
[](https://jasperapp.io/)
|
||||
|
||||
This "stream" is the core feature of Jasper. For example, if you want to see "issues that are assigned to @zeke in the electron/electron repository", you create the following stream:
|
||||
|
||||
```
|
||||
repo:electron/electron assignee:zeke is:issue
|
||||
```
|
||||
|
||||
[](https://jasperapp.io/)
|
||||
|
||||
After creating the stream and waiting for a few seconds, you can see the issues that meet the conditions.
|
||||
|
||||
[](https://jasperapp.io/)
|
||||
|
||||
## What can we do with streams?
|
||||
|
||||
I will introduce what kind of conditions can be used for stream.
|
||||
|
||||
### Users and Teams
|
||||
|
||||
| Stream | Issues |
|
||||
| ---- | --- |
|
||||
| `mentions:cat mentions:dog` | Issues that mention user `cat` or `dog`|
|
||||
| `author:cat author:dog` | Issues created by user `cat` or `dog` |
|
||||
| `assignee:cat assignee:dog` | Issues assigned to `cat` or `dog` |
|
||||
| `commenter:cat commenter:dog` | Issues that `cat` or `dog` commented on |
|
||||
| `involves:cat involves:dog` | Issues that "involve" `cat` or `bob` |
|
||||
| `team:animal/white-cat team:animal/black-dog` | Issues that `animal/white-cat` or `animal/black-dog` are mentioned in |
|
||||
|
||||
`involves` means `mention`, `author`, `assignee` or `commenter`
|
||||
|
||||
### Repositories and Organizations
|
||||
|
||||
| Stream | Issues |
|
||||
| --- | --- |
|
||||
| `repo:cat/jump repo:dog/run` | Issues in `cat/jump` or `dog/run` |
|
||||
| `org:electron user:cat user:dog` | Issues in `electron`, `cat` or `dog` |
|
||||
|
||||
`org` is same as `user`
|
||||
|
||||
### Attributes
|
||||
|
||||
| Stream | Issues |
|
||||
| --- | --- |
|
||||
| `repo:cat/jump milestone:v1.0.0 milestone:v1.0.1` | Issues that are attached to `v1.0.0` or `v1.0.1` in `cat/jump` |
|
||||
| `repo:cat/jump label:bug label:blocker` | Issues that are attached `bug` **and** `blocker` in `cat/jump` |
|
||||
| `electron OR atomshell` | Issues that include `electron` or `atomshell` |
|
||||
|
||||
### Review Status
|
||||
|
||||
| Stream | Issues |
|
||||
| --- | --- |
|
||||
| `is:pr review:required` | Issues that are required review in `cat/jump` |
|
||||
| `is:pr review-requested:cat` | Issues that are requested review by `cat`. <br/> But these are not reviewed yet. |
|
||||
| `is:pr reviewed-by:cat` | Issues that are reviewed by `cat` |
|
||||
|
||||
<br/>
|
||||
|
||||
As you may have noticed by looking at these, streams can use GitHub's search queries.
|
||||
For details on how to use streams and search queries, see the following URLs.
|
||||
|
||||
- [jasperapp.io/doc.html#stream](https://jasperapp.io/doc.html#stream)
|
||||
- [help.github.com/articles/searching-issues](https://help.github.com/articles/searching-issues/)
|
||||
- [help.github.com/articles/search-syntax](https://help.github.com/articles/search-syntax/)
|
||||
|
||||
Jasper also has features for unread issue management, unread comment management, marking stars, notification updating, filtering issues, keyboard shortcuts, etc.
|
||||
|
||||
## Is Jasper a paid product? How much does it cost?
|
||||
|
||||
Jasper is $12. However you can use the [free trial edition](https://jasperapp.io/) for 30 days.
|
||||
|
||||
## Why did you choose to build Jasper on Electron?
|
||||
|
||||
I like the following aspects of Electron:
|
||||
|
||||
- Apps can be developed with JavaScript/CSS/HTML.
|
||||
- Apps can be built for Windows, Mac, and Linux platforms.
|
||||
- Electron is actively developed and has a large community.
|
||||
|
||||
These features enable rapid and simple desktop application development. It is awesome! If you have any product idea, you should consider using Electron by all means.
|
||||
|
||||
## What are some challenges you've faced while developing Jasper?
|
||||
|
||||
I had a hard time figuring out the "stream" concept. At first I considered using GitHub's [Notifications API]. However I noticed that it does not support certain use cases. After that I considered using the [Issues API] and [Pull Requests API], in addition to the Notification API. But it never became what I wanted. Then while thinking about various methods, I realized that polling GitHub's [Search API] would offer the most flexibility. It took about a month of experimentation to get to this point, then I implemented a prototype of Jasper with the stream concept in two days.
|
||||
|
||||
Note: The polling is limited to once every 10 seconds at most. This is acceptable enough for the restriction of GitHub API.
|
||||
|
||||
## What's coming next?
|
||||
|
||||
I have a plan to develop the following features:
|
||||
|
||||
- **A filtered stream**: A stream has some filtered stream that filter issues in the stream. It is like as view of SQL.
|
||||
- **Multiple accounts**: you will be able to use both github.com and GHE
|
||||
- **Improve performance**: For now the loading a issue in WebView is low speed than normal browser.
|
||||
|
||||
Follow [@jasperappio](https://twitter.com/jasperappio) on Twitter for updates.
|
||||
|
||||
[Jasper]: https://jasperapp.io
|
||||
[Notifications API]: https://developer.github.com/v3/activity/notifications/
|
||||
[Pull Requests API]: https://developer.github.com/v3/pulls/
|
||||
[Issues API]: https://developer.github.com/v3/issues/
|
||||
[Search API]: https://developer.github.com/v3/search/
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
---
|
||||
title: 'July 2016: New Apps and Meetups'
|
||||
author: jlord
|
||||
date: '2016-08-04'
|
||||
---
|
||||
|
||||
We're starting a monthly roundup to highlight activity in the Electron community. Each roundup will feature things like new apps, upcoming meetups, tools, videos, etc.
|
||||
|
||||
---
|
||||
|
||||
This site is updated with new [apps](https://electronjs.org/apps) and [meetups](https://electronjs.org/community) through [pull requests](https://github.com/electron/electronjs.org/pulls) from the community. You can [watch the repository](https://github.com/electron/electronjs.org) to get notifications of new additions or if you're not interested in _all_ of the site's changes, subscribe to the [blog RSS feed](https://electronjs.org/feed.xml).
|
||||
|
||||
If you've made an Electron app or host a meetup, make a [pull request](https://github.com/electron/electronjs.org) to add it to the site and it will make the next roundup.
|
||||
|
||||
### New Apps
|
||||
|
||||
{: .table .table-ruled .table-full-width .table-with-spacious-first-column .mb-7}
|
||||
| | | |
|
||||
| --- | --- | -- |
|
||||
| <img src="/images/apps/demio.png" width="50"/> | [Demio](https://demio.com) | A Webinar platform built for inbound sales and marketing |
|
||||
| <img src="/images/apps/electorrent.png" width="50"/> | [Electorrent](https://github.com/Tympanix/Electorrent) | A remote client app for uTorrent server |
|
||||
| <img src="/images/apps/phonegap.png" width="50"/> | [PhoneGap](http://phonegap.com/products/#desktop-app-section) | The open source framework that gets you building amazing mobile apps using web technology |
|
||||
| <img src="/images/apps/wordmark.png" width="50"/> | [WordMark](http://wordmarkapp.com) | A lightweight blog publishing editor for Markdown writers |
|
||||
| <img src="/images/apps/ubauth.png" width="50"/> | [UbAuth](http://ubauth.enytc.com) | App to help developers create access tokens for Uber applications with OAuth 2.0 |
|
||||
| <img src="/images/apps/hyperterm.png" width="50"/> | [HyperTerm](https://hyperterm.org) | HTML/JS/CSS terminal |
|
||||
| <img src="/images/apps/marp.png" width="50"/> | [Marp](https://yhatt.github.io/marp) | Markdown presentation writer |
|
||||
| <img src="/images/apps/glyphrstudio.png" width="50"/> | [Glyphr Studio](https://github.com/glyphr-studio/Glyphr-Studio-Desktop) | A free, web based font designer, focusing on font design for hobbyists |
|
||||
| <img src="/images/apps/bitcrypt.png" width="50"/> | [BitCrypt](https://github.com/Nazgul07/BitCrypt) | A simple file encryption application for Windows Encrypt your bits |
|
||||
| <img src="/images/apps/trym.png" width="50"/> | [Trym](http://kontentapps.com/trym) | Beautiful small app for macOS to help you view, optimize and convert SVG icons |
|
||||
| <img src="/images/apps/booker.png" width="50"/> | [Booker](http://apps.meamka.me/booker) | Text editor with the power of Markdown |
|
||||
| <img src="/images/apps/phonepresenter.png" width="50"/> | [PhonePresenter](https://phonepresenter.com) | The smartest presentation clicker |
|
||||
| <img src="/images/apps/yout-player.png" width="50"/> | [Yout](https://youtplayer.github.io) | The new way to watch your playlists from YouTube on desktop |
|
||||
|
||||
### New Meetups
|
||||
|
||||
{: .table .table-ruled .table-full-width .table-with-spacious-first-column .mb-7}
|
||||
| | |
|
||||
| --- | -- |
|
||||
| [Electron Open Source Desktop Framework](http://www.meetup.com/Electron-Open-Source-Desktop-Framework/) | London, UK |
|
||||
90
blog/kap.md
90
blog/kap.md
|
|
@ -1,90 +0,0 @@
|
|||
---
|
||||
title: 'Project of the Week: Kap'
|
||||
author:
|
||||
- skllcrn
|
||||
- sindresorhus
|
||||
- zeke
|
||||
date: '2017-01-31'
|
||||
---
|
||||
|
||||
The Electron community is growing quickly, and people are creating powerful
|
||||
new apps and tools at an astounding rate. To celebrate this creative momentum
|
||||
and keep the community informed of some of these new projects, we've decided to
|
||||
start a weekly blog series featuring noteworthy Electron-related projects.
|
||||
|
||||
---
|
||||
|
||||
This post is the first in the series, and features [Kap](https://getkap.co/),
|
||||
an open-source screen recording app built by [Wulkano](https://wulkano.com/),
|
||||
a geodistributed team of freelance designers and developers.
|
||||
|
||||
[](https://getkap.co/)
|
||||
|
||||
## What is Kap?
|
||||
|
||||
[Kap is an open-source screen recorder](https://getkap.co) built primarily for designers and developers to easily capture their work. People use it to share animated prototypes, document bugs, create silly GIFs and everything in-between.
|
||||
|
||||
We've seen people of all ages and backgrounds use it in educational settings, screencasts, tutorials... the list goes on. Even to create production assets! We're completely blown away by how well received our little side project has been.
|
||||
|
||||
## Why did you build it?
|
||||
|
||||
That's a very good question, it's not like there's a lack of screen recorders out there! We felt the alternatives were either too complex, too expensive or too limited. Nothing felt *just right* for our everyday needs. We also think it's great when the tools we use to do our work are open-source, that way everyone can help shape them. [Building Kap ended up being just as much about what we didn't do](https://medium.com/wulkano-friends/from-idea-to-product-and-beyond-a12850403c38). It's all in the details, an accumulation of small improvements that became the outline of a tool we wanted to use.
|
||||
|
||||
However, and maybe most importantly, Kap has become a place for us to leave our worries at the door and just have fun building something for ourselves and people like us. It's so important to create an environment where you get to just vent, try new thins and enjoy your craft. No requirements, no pressure, no expectations. Should designers and developers side project? Why, yes. Yes, they should.
|
||||
|
||||
## Why did you choose to build Kap on Electron?
|
||||
|
||||
There were a number of reasons:
|
||||
|
||||
* Web tech
|
||||
* Most of the team are web developers
|
||||
* We're invested in JavaScript
|
||||
* It opens the door for more people to contribute
|
||||
* Electron itself is open-source
|
||||
* The power and easily maintainable modularity of `node_modules`
|
||||
* Cross-platform possibilities
|
||||
|
||||
We think the future of apps are in the browser, but we're not quite there yet. Electron is an important step in the journey towards that future. It not only makes the apps themselves more accessible, but also the code they're built with. An interesting thought is imagining a future where the OS is a browser, and the tabs are essentially Electron apps.
|
||||
|
||||
Additionally, being primarily web developers, we're big fans of the isomorphic nature of JavaScript, in that you can run JS on the client, server, and now the desktop. With web tech (HTML, CSS and JS), many things are much simpler than native: Faster prototyping, less code, flexbox > auto-layout (macOS/iOS).
|
||||
|
||||
## What are some challenges you've faced while building Kap?
|
||||
|
||||
Using the resources Electron has available to record the screen was the biggest challenge. They simply weren't performant enough to meet our requirements and would render the project a failure in our eyes. Though at no fault of Electron itself, there's still a gap between native development and building desktop apps with web tech.
|
||||
|
||||
We spent a lot of time trying to work around the poor performance of the `getUserMedia` API, an issue originating in Chromium. One of our main goals when we set out to make Kap was to build the entire app with web tech. After trying everything we could to get it working (the minimum requirement being 30 FPS on a Retina screen), we eventually had to find another solution.
|
||||
|
||||
## I see some Swift code in the repo. What's that about?
|
||||
|
||||
Being forced to look for alternatives to `getUserMedia`, we started experimenting with `ffmpeg`. Besides being one of the best tools for audio and video conversion it has the functionality of recording the screen in almost any OS, and we were able to record crispy video meeting our minimum requirement of 30 FPS on a Retina screen. Problem? The performance was ":weary:", the CPU usage was going haywire. So we went back to the drawing board, discussed our options and realised that we had to make a compromise. That resulted in [Aperture](https://github.com/wulkano/aperture), our own screen recording library for macOS written in Swift.
|
||||
|
||||
## In what areas should Electron be improved?
|
||||
|
||||
We all know that Electron apps can have a thing for using RAM, but again, that's really a Chromium thing. It's part of how it works and it really depends on what you're running, for example Kap and Hyper typically use less than 100MB of memory.
|
||||
|
||||
One of the biggest areas of improvement that we see is payload, particularly how Electron distributes Chromium. One idea would be to have a shared Electron core and make app installers check if it's already present on the system.
|
||||
|
||||
Creating cross-platform Electron apps could be a better experience. Right now there are too many inconsistencies, platform-specific APIs, and missing features between platforms, making your codebase littered with if-else statements. For example, vibrancy is only supported on macOS, the auto-updater works differently on macOS and Windows, and is not even supported on Linux. Transparency is a hit or miss on Linux, usually miss.
|
||||
|
||||
It should also be easier to call native system APIs. Electron comes with a very good set of APIs, but sometimes you need functionality it doesn't provide. Creating a native Node.js addon is an option, but it's painful to work with. Ideally Electron would ship with a good [FFI](https://en.wikipedia.org/wiki/Foreign_function_interface) API, like [`fastcall`](https://github.com/cmake-js/fastcall). This would have enabled us to write the Swift part in JavaScript instead.
|
||||
|
||||
## What are your favorite things about Electron?
|
||||
|
||||
Our favorite thing is easily the fact that anyone with knowledge of creating for the web can build and contribute to multi-platform native experiences. Not to mention the ease and joy of developing on it, the excellent documentation and the thriving ecosystem.
|
||||
|
||||
From a front-end perspective, building Kap felt no different than building a simple website using browser APIs. Electron does a really great job of making app development similar (basically identical) to web development. So simple in fact that there was no need for frameworks or similar to help us, just clean and modular JS and CSS.
|
||||
|
||||
We are also huge fans of the team building it, their dedication and support, and the active and friendly community they maintain. Hugs to all of you!
|
||||
|
||||
## What's coming next in Kap?
|
||||
|
||||
The next step for us is to review the app in preparation for our 2.0.0 milestone, which includes a React re-write in addition to support for plugins, allowing developers to extend the functionality of Kap! We invite everyone to follow to project and contribute on our [GitHub repository](https://github.com/wulkano/kap). We're listening and want to hear from as many of you as possible, [let us know how we can make Kap the best possible tool it can be for you](https://wulkano.typeform.com/to/BIvJKz)!
|
||||
|
||||
## What is Wulkano?
|
||||
|
||||
[Wulkano](https://wulkano.com) is a design studio and digital collective, a team of remote technologists who love working together on both client gigs and our own projects. We're a distributed but tight knit group of people from different places and backgrounds, sharing knowledge, ideas, experiences, but most importantly silly GIFs and memes, in our virtual office (which happens to be the Electron based Slack!).
|
||||
|
||||
## Any Electron tips that might be useful to other developers?
|
||||
|
||||
Take advantage of and get involved in the fantastic [community](https://discuss.atom.io/c/electron), check out [Awesome Electron](https://github.com/sindresorhus/awesome-electron), look at [examples](https://github.com/electron/electron-api-demos) and make use of the great [docs](https://electronjs.org/docs/)!
|
||||
|
||||
|
|
@ -1,76 +0,0 @@
|
|||
---
|
||||
title: Use V8 and Chromium Features in Electron
|
||||
author: jlord
|
||||
date: '2016-01-07'
|
||||
---
|
||||
|
||||
Building an Electron application means you only need to create one codebase and design for one browser, which is pretty handy. But because Electron stays up to date with [Node.js](http://nodejs.org) and [Chromium](https://www.chromium.org) as they release, you also get to make use of the great features they ship with. In some cases this eliminates dependencies you might have previously needed to include in a web app.
|
||||
|
||||
---
|
||||
|
||||
There are many features and we'll cover some here as examples, but if you're interested in learning about all features you can keep an eye on the [Google Chromium blog](http://blog.chromium.org) and [Node.js changelogs](https://nodejs.org/en/download/releases). You can see what versions of Node.js, Chromium and V8 Electron is using at [electronjs.org/#electron-versions](https://electronjs.org/#electron-versions).
|
||||
|
||||
## ES6 Support through V8
|
||||
|
||||
Electron combines Chromium's rendering library with Node.js. The two share the same JavaScript engine, [V8](https://developers.google.com/v8). Many ECMAScript 2015 (ES6) features are already built into V8 which means you can use them in your Electron application without any compilers.
|
||||
|
||||
Below are a few examples but you can also get classes (in strict mode), block scoping, promises, typed arrays and more. Check out [this list](https://nodejs.org/en/docs/es6/) for more information on ES6 features in V8.
|
||||
|
||||
**Arrow Functions**
|
||||
|
||||
```js
|
||||
findTime () => {
|
||||
console.log(new Date())
|
||||
}
|
||||
```
|
||||
**String Interpolation**
|
||||
|
||||
```js
|
||||
var octocat = "Mona Lisa";
|
||||
console.log(`The octocat's name is ${octocat}`);
|
||||
```
|
||||
|
||||
**New Target**
|
||||
|
||||
```js
|
||||
Octocat() => {
|
||||
if (!new.target) throw "Not new";
|
||||
console.log("New Octocat");
|
||||
}
|
||||
|
||||
// Throws
|
||||
Octocat();
|
||||
// Logs
|
||||
new Octocat();
|
||||
```
|
||||
|
||||
**Array Includes**
|
||||
|
||||
```js
|
||||
// Returns true
|
||||
[1, 2].includes(2);
|
||||
```
|
||||
|
||||
**Rest Parameters**
|
||||
|
||||
```js
|
||||
// Represent indefinite number of arguments as an array
|
||||
(o, c, ...args) => {
|
||||
console.log(args.length)
|
||||
}
|
||||
```
|
||||
|
||||
## Chromium Features
|
||||
|
||||
Thanks to all the hard work Google and contributors put into Chromium, when you build Electron apps you can also use cool things like (but not limited to):
|
||||
|
||||
- [MouseEvent.getModifierState()](https://googlechrome.github.io/samples/mouseevent-get-modifier-state/index.html)
|
||||
- [CSS.escape()](https://googlechrome.github.io/samples/css-escape/index.html)
|
||||
- [Fetch API Streaming](https://googlechrome.github.io/samples/fetch-api/fetch-response-stream.html)
|
||||
|
||||
Follow along with the [Google Chromium blog](http://blog.chromium.org) to learn about features as new versions ship and again, you can check the version of Chromium that Electron uses [here](https://electronjs.org/#electron-versions).
|
||||
|
||||
## What are you excited about?
|
||||
|
||||
Tweet to us [@ElectronJS](https://twitter.com/electronjs) with your favorite features built into V8 or Chromium.
|
||||
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
---
|
||||
title: Discontinuing support for 32-bit Linux
|
||||
author: felixrieseberg
|
||||
date: '2019-03-04'
|
||||
---
|
||||
|
||||
The Electron team will discontinue support for 32-bit Linux (ia32 / i386) starting with Electron v4.0. The last version of Electron that supports 32-bit based installations of Linux is Electron v3.1, which will receive support releases until Electron v6 is released. Support for 64-bit based Linux and `armv7l` will continue unchanged.
|
||||
|
||||
---
|
||||
|
||||
## What exactly is Electron no longer supporting?
|
||||
|
||||
You may have seen the description "64-bit" and "32-bit" as stickers on your computer or as options for downloading software. The term is used to describe a specific computer architecture. Most computers made in the 1990s and early 2000s were made with CPUs that were based on the 32-bit architecture, while most computers made later were based on the newer and more powerful 64-bit architecture. The Nintendo 64 (get it?) and the PlayStation 2 were the first widely available consumer devices with the new architecture, computers sold after 2010 contained almost exclusively 64-bit processors. As a result, support has been shrinking: Google stopped releasing Chrome for 32-bit Linux in March 2016, Canonical stopped providing 32-bit desktop images in 2017 and dropped support for 32-bit altogether with Ubuntu 18.10. Arch Linux, elementary OS, and other prominent Linux distributions have already dropped support for the aging processor architecture.
|
||||
|
||||
Until now, Electron has provided and supported builds that run on the older 32-bit architecture. From release v4.0 onwards, the Electron team will no longer be able to provide binaries or support for 32-bit Linux.
|
||||
|
||||
Electron has always been a vibrant open source project and we continue to support and encourage developers interested in building Electron for exotic architectures.
|
||||
|
||||
## What does that mean for developers?
|
||||
|
||||
If you are not currently providing 32-bit distributions of your app for Linux, no action is required.
|
||||
|
||||
Projects which ship 32-bit Linux Electron applications will need to decide how to proceed. 32-bit Linux will be supported on Electron 3 [until](https://electronjs.org/docs/tutorial/support#supported-versions) the release of Electron 6, which gives some time to make decisions and plans.
|
||||
|
||||
## What does that mean for users?
|
||||
|
||||
If you are a Linux user and not sure whether or not you're running a 64-bit based system, you are likely running on a 64-bit based architecture. To make sure, you can run the `lscpu` or `uname -m` commands in your terminal. Either one will print your current architecture.
|
||||
|
||||
If you are using Linux on a 32-bit processor, you have likely already encountered difficulties finding recently released software for your operating system. The Electron team joins other prominent members in the Linux community by recommending that you upgrade to a 64-bit based architecture.
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
---
|
||||
title: SQLite Vulnerability Fix
|
||||
author: ckerr
|
||||
date: '2018-12-18'
|
||||
---
|
||||
|
||||
A remote code execution vulnerability, "[Magellan](https://blade.tencent.com/magellan/index_en.html)," has been discovered affecting software based on SQLite or Chromium, including all versions of Electron.
|
||||
|
||||
---
|
||||
|
||||
## Scope
|
||||
|
||||
Electron applications using Web SQL are impacted.
|
||||
|
||||
|
||||
## Mitigation
|
||||
|
||||
Affected apps should stop using Web SQL or upgrade to a patched version of Electron.
|
||||
|
||||
We've published new versions of Electron which include fixes for this vulnerability:
|
||||
* [4.0.0-beta.11](https://github.com/electron/electron/releases/tag/v4.0.0-beta.11)
|
||||
* [3.1.0-beta.4](https://github.com/electron/electron/releases/tag/v3.1.0-beta.4)
|
||||
* [3.0.13](https://github.com/electron/electron/releases/tag/v3.0.13)
|
||||
* [2.0.16](https://github.com/electron/electron/releases/tag/v2.0.16)
|
||||
|
||||
There are no reports of this in the wild; however, affected applications are urged to mitigate.
|
||||
|
||||
## Further Information
|
||||
|
||||
This vulnerability was discovered by the Tencent Blade team, who have published [a blog post that discusses the vulnerability](https://blade.tencent.com/magellan/index_en.html).
|
||||
|
||||
To learn more about best practices for keeping your Electron apps secure, see our [security tutorial].
|
||||
|
||||
If you wish to report a vulnerability in Electron, email security@electronjs.org.
|
||||
|
||||
[security tutorial]: https://electronjs.org/docs/tutorial/security
|
||||
|
|
@ -1,194 +0,0 @@
|
|||
---
|
||||
title: "Electron's New Internationalized Website"
|
||||
author: zeke
|
||||
date: '2017-11-13'
|
||||
---
|
||||
|
||||
Electron has a new website at [electronjs.org]! We've replaced
|
||||
our static Jekyll site with a Node.js webserver, giving us flexibility to
|
||||
internationalize the site and paving the way for more exciting new features.
|
||||
|
||||
---
|
||||
|
||||
## 🌍 Translations
|
||||
|
||||
We've begun the process of internationalizing the website with the
|
||||
goal of making Electron app development accessible to a global audience of
|
||||
developers. We're using a localization platform called [Crowdin] that integrates
|
||||
with GitHub, opening and updating pull requests automatically as content is translated into different languages.
|
||||
|
||||
<figure>
|
||||
<a href="https://electronjs.org/languages">
|
||||
<img src="https://user-images.githubusercontent.com/2289/32803530-a35ff774-c938-11e7-9b98-5c0cfb679d84.png" alt="Electron Nav in Simplified Chinese"/>
|
||||
<figcaption>Electron's Nav in Simplified Chinese</figcaption>
|
||||
</a>
|
||||
</figure>
|
||||
|
||||
Though we've been working quietly on this effort so far,
|
||||
over 75 Electron community members have already discovered the project
|
||||
organically and joined in the effort to internationalize the website and
|
||||
translate Electron's docs into over 20 languages. We are seeing [daily
|
||||
contributions](https://github.com/electron/electron-i18n/pulls?utf8=%E2%9C%93&q=is%3Apr%20author%3Aglotbot%20) from people all over the world, with translations for
|
||||
languages like French, Vietnamese, Indonesian, and Chinese leading the way.
|
||||
|
||||
To choose your language and view translation progress, visit [electronjs.org/languages](https://electronjs.org/languages)
|
||||
|
||||
<figure>
|
||||
<a href="https://electronjs.org/languages">
|
||||
<img class="screenshot" src="https://user-images.githubusercontent.com/2289/32754734-e8e43c04-c886-11e7-9f34-f2da2bb4357b.png" alt="Current target languages on Crowdin"/>
|
||||
<figcaption>Translations in progress on Crowdin</figcaption>
|
||||
</a>
|
||||
</figure>
|
||||
|
||||
If you're multilingual and interested in helping translate Electron's docs
|
||||
and website, visit the [electron/electron-i18n] repo, or jump right into
|
||||
translating on [Crowdin], where you can sign in using your GitHub account.
|
||||
|
||||
There are currently 21 languages enabled for the Electron project on Crowdin.
|
||||
Adding support for more languages is easy, so if you're interested in
|
||||
helping translate but you don't see your language listed,
|
||||
[let us know](https://github.com/electron/electronjs.org/issues/new) and
|
||||
we'll enable it.
|
||||
|
||||
## Raw Translated Docs
|
||||
|
||||
If you prefer to read documentation in raw markdown files, you
|
||||
can now do that in any language:
|
||||
|
||||
```sh
|
||||
git clone https://github.com/electron/electron-i18n
|
||||
ls electron-i18n/content
|
||||
```
|
||||
|
||||
## App Pages
|
||||
|
||||
As of today, any Electron app can easily have its own page on the Electron
|
||||
site. For a few examples, check out
|
||||
[Etcher](https://electronjs.org/apps/etcher),
|
||||
[1Clipboard](https://electronjs.org/apps/1clipboard), or
|
||||
[GraphQL Playground](https://electronjs.org/apps/graphql-playground), pictured
|
||||
here on the Japanese version of the site:
|
||||
|
||||
<figure>
|
||||
<a href="https://electronjs.org/apps/graphql-playground">
|
||||
<img class="screenshot" src="https://user-images.githubusercontent.com/2289/32871096-f5043292-ca33-11e7-8d03-a6a157aa183d.png" alt="GraphQL Playground"/>
|
||||
</a>
|
||||
</figure>
|
||||
|
||||
There are some incredible Electron apps out there, but they're not always easy
|
||||
to find, and not every developer has the time or resources to build a proper
|
||||
website to market and distribute their app.
|
||||
|
||||
Using just a
|
||||
[PNG icon file and a small amount of app metadata](https://github.com/electron/electron-apps/blob/master/contributing.md),
|
||||
we're able to collect a lot of information about a given app.
|
||||
Using data collected from GitHub, app pages can now display screenshots,
|
||||
download links, versions, release notes, and READMEs for every app that
|
||||
has a public repository. Using a color palette extracted from each app's icon,
|
||||
we can produce [bold and accessible colors](https://github.com/zeke/pick-a-good-color)
|
||||
to give each app page some visual distinction.
|
||||
|
||||
The [apps index page](https://electronjs.org/apps) now also has categories
|
||||
and a keyword filter to find interesting apps like [GraphQL GUIs](https://electronjs.org/apps?q=graphql)
|
||||
and [p2p tools](https://electronjs.org/apps?q=graphql).
|
||||
|
||||
If you've got an Electron app that you'd like featured on the site, open a
|
||||
pull request on the [electron/electron-apps] repository.
|
||||
|
||||
## One-line Installation with Homebrew
|
||||
|
||||
The [Homebrew] package manager for macOS has a subcommand called [cask]
|
||||
that makes it easy to install desktop apps using a single command in your
|
||||
terminal, like `brew cask install atom`.
|
||||
|
||||
We've begun collecting Homebrew cask names for popular Electron apps and are now
|
||||
displaying the installation command (for macOS visitors) on every app page
|
||||
that has a cask:
|
||||
|
||||
<figure>
|
||||
<a href="https://electronjs.org/apps/dat">
|
||||
<img class="screenshot" src="https://user-images.githubusercontent.com/2289/32871246-c5ef6f2a-ca34-11e7-8eb4-3a5b93b91007.png"/>
|
||||
<figcaption>Installation options tailored for your platform: macOS, Windows, Linux</figcaption>
|
||||
</a>
|
||||
</figure>
|
||||
|
||||
To view all the apps that have homebrew cask names, visit
|
||||
[electronjs.org/apps?q=homebrew](https://electronjs.org/apps?q=homebrew). If
|
||||
you know of other apps with casks that we haven't indexed yet,
|
||||
[please add them!](https://github.com/electron/electron-apps/blob/master/contributing.md)
|
||||
|
||||
## 🌐 A New Domain
|
||||
|
||||
We've moved the site from electron.atom.io to a new domain: [electronjs.org].
|
||||
|
||||
The Electron project was born inside [Atom], GitHub's open-source text editor
|
||||
built on web technologies. Electron was originally called `atom-shell`. Atom
|
||||
was the first app to use it, but it didn't take long for folks to realize that
|
||||
this magical Chromium + Node runtime could be used for all kinds of different
|
||||
applications. When companies like Microsoft and Slack started to make use of
|
||||
`atom-shell`, it became clear that the project needed a new name.
|
||||
|
||||
And so "Electron" was born. In early 2016, GitHub assembled a new team to focus
|
||||
specifically on Electron development and maintenance, apart from Atom. In the
|
||||
time since, Electron has been adopted by thousands of app developers, and is now
|
||||
depended on by many large companies, many of which have Electron teams of
|
||||
their own.
|
||||
|
||||
Supporting GitHub's Electron projects like Atom and [GitHub Desktop] is still a
|
||||
priority for our team, but by moving to a new domain we hope to help clarify
|
||||
the technical distinction between Atom and Electron.
|
||||
|
||||
## 🐢🚀 Node.js Everywhere
|
||||
|
||||
The previous Electron website was built with [Jekyll], the popular Ruby-based
|
||||
static site generator. Jekyll is a great tool for building static websites, but
|
||||
the website had started to outgrow it. We wanted more dynamic capabilities like proper redirects and dynamic content rendering, so a [Node.js] server was the obvious choice.
|
||||
|
||||
The Electron ecosystem includes projects with components written in many
|
||||
different programming languages, from Python to C++ to Bash. But JavaScript is foundational to Electron, and it's the language used most in our community.
|
||||
|
||||
By migrating the website from Ruby to Node.js, we aim to lower the barrier to
|
||||
entry for people wishing to contribute to the website.
|
||||
|
||||
## ⚡️ Easier Open-Source Participation
|
||||
|
||||
If you've got [Node.js] (8 or higher) and
|
||||
[git](https://git-scm.org) installed on your system, you can easily get the
|
||||
site running locally:
|
||||
|
||||
```sh
|
||||
git clone https://github.com/electron/electronjs.org
|
||||
cd electronjs.org
|
||||
npm install
|
||||
npm run dev
|
||||
```
|
||||
|
||||
The new website is hosted on Heroku. We use deployment pipelines and the
|
||||
[Review Apps](https://devcenter.heroku.com/articles/github-integration-review-apps)
|
||||
feature, which automatically creates a running copy of the app for every pull
|
||||
request. This makes it easy for reviewers to view the actual effects of a
|
||||
pull request on a live copy of the site.
|
||||
|
||||
## 🙏 Thanks to Contributors
|
||||
|
||||
We'd like to give special thanks to all the folks around the world who have
|
||||
contributed their own time and energy to help improve Electron. The passion of
|
||||
the open-source community has helped immeasurably in making Electron a success.
|
||||
Thank you!
|
||||
|
||||
<figure>
|
||||
<img src="https://user-images.githubusercontent.com/2289/32871386-92eaa4ea-ca35-11e7-9511-a746c7fbf2c4.png"/>
|
||||
</figure>
|
||||
|
||||
|
||||
[Atom]: https://atom.io
|
||||
[cask]: https://caskroom.github.io
|
||||
[crowdin.com/project/electron]: https://crowdin.com/project/electron
|
||||
[Crowdin]: https://crowdin.com/project/electron
|
||||
[electron/electron-apps]: https://github.com/electron/electron-apps
|
||||
[electron/electron-i18n]: https://github.com/electron/electron-i18n#readme
|
||||
[electronjs.org]: https://electronjs.org
|
||||
[GitHub Desktop]: https://desktop.github.com
|
||||
[Homebrew]: https://brew.sh
|
||||
[Jekyll]: https://jekyllrb.com
|
||||
[Node.js]: https://nodejs.org
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
title: Node.js Native Addons and Electron 5.0
|
||||
author: BinaryMuse
|
||||
date: '2019-02-01'
|
||||
---
|
||||
|
||||
If you're having trouble using a native Node.js addon with Electron 5.0, there's a chance it needs to be updated to work with the most recent version of V8.
|
||||
|
||||
---
|
||||
|
||||
## Goodbye `v8::Handle`, Hello `v8::Local`
|
||||
|
||||
In 2014, the V8 team deprecated `v8::Handle` in favor of `v8::Local` for local handles. Electron 5.0 includes a version of V8 that has finally removed `v8::Handle` for good, and native Node.js addons that still use it will need to be updated before they can be used with Electron 5.0.
|
||||
|
||||
The required code change is minimal, but *every* native Node module that still uses `v8::Handle` will fail to build with Electron 5.0 and will need to be modified. The good news is that Node.js v12 will also include this V8 change, so any modules that use `v8::Handle` will need to be updated *anyway* to work with the upcoming version of Node.
|
||||
|
||||
## I maintain a native addon, how can I help?
|
||||
|
||||
If you maintain a native addon for Node.js, ensure you replace all occurrences of `v8::Handle` with `v8::Local`. The former was just an alias of the latter, so no other changes need to be made to address this specific issue.
|
||||
|
||||
You may also be interested in looking into [N-API](https://nodejs.org/api/n-api.html), which is maintained separately from V8 as a part of Node.js itself, and aims to insulate native addons from changes in the underlying JavaScript engine. You can find more information [in the N-API documentation on the Node.js website](https://nodejs.org/api/n-api.html#n_api_n_api).
|
||||
|
||||
## Help! I use a native addon in my app and it won't work!
|
||||
|
||||
If you're consuming a native addon for Node.js in your app and the native addon will not build because of this issue, check with the author of the addon to see if they've released a new version that fixes the problem. If not, reaching out to the author (or [opening a Pull Request!](https://help.github.com/articles/about-pull-requests/)) is probably your best bet.
|
||||
|
|
@ -1,79 +0,0 @@
|
|||
---
|
||||
title: npm install electron
|
||||
author: zeke
|
||||
date: '2016-08-16'
|
||||
---
|
||||
|
||||
As of Electron version 1.3.1, you can `npm install electron --save-dev` to
|
||||
install the latest precompiled version of Electron in your app.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
## The prebuilt Electron binary
|
||||
|
||||
If you've ever worked on an Electron app before, you've likely come across the
|
||||
`electron-prebuilt` npm package. This package is an indispensable part of nearly
|
||||
every Electron project. When installed, it detects your operating system
|
||||
and downloads a prebuilt binary that is compiled to work on your system's
|
||||
architecture.
|
||||
|
||||
## The new name
|
||||
|
||||
The Electron installation process was often a stumbling block for new developers.
|
||||
Many brave people tried to get started developing an Electron by app by running
|
||||
`npm install electron` instead of `npm install electron-prebuilt`,
|
||||
only to discover (often after much confusion) that it was not the `electron`
|
||||
they were looking for.
|
||||
|
||||
This was because there was an existing `electron` project on npm,
|
||||
created before GitHub's Electron project existed. To help make Electron
|
||||
development easier and more intuitive for new developers, we reached out to the
|
||||
owner of the existing `electron` npm package to ask if he'd be willing to let us use
|
||||
the name. Luckily he was a fan of our project, and agreed to help us repurpose
|
||||
the name.
|
||||
|
||||
## Prebuilt lives on
|
||||
|
||||
As of version 1.3.1, we have begun publishing
|
||||
[`electron`](https://www.npmjs.com/package/electron) and `electron-prebuilt`
|
||||
packages to npm in tandem. The two packages are identical. We chose to continue publishing
|
||||
the package under both names for a while so as not to inconvenience the
|
||||
thousands of developers who are currently using `electron-prebuilt` in their projects.
|
||||
We recommend updating your `package.json` files to use the new `electron` dependency,
|
||||
but we will continue releasing new versions of `electron-prebuilt` until the
|
||||
end of 2016.
|
||||
|
||||
The [electron-userland/electron-prebuilt](https://github.com/electron-userland/electron-prebuilt)
|
||||
repository will remain the canonical home of the `electron` npm package.
|
||||
|
||||
## Many thanks
|
||||
|
||||
We owe a special thanks to [@mafintosh](https://github.com/mafintosh),
|
||||
[@maxogden](https://github.com/maxogden), and many other [contributors](https://github.com/electron-userland/electron-prebuilt/graphs/contributors)
|
||||
for creating and maintaining `electron-prebuilt`, and for their tireless service
|
||||
to the JavaScript, Node.js, and Electron communities.
|
||||
|
||||
And thanks to [@logicalparadox](https://github.com/logicalparadox) for allowing
|
||||
us to take over the `electron` package on npm.
|
||||
|
||||
## Updating your projects
|
||||
|
||||
We've worked with the community to update popular packages that are affected
|
||||
by this change. Packages like
|
||||
[electron-packager](https://github.com/electron-userland/electron-packager),
|
||||
[electron-rebuild](https://github.com/electron/electron-rebuild), and
|
||||
[electron-builder](https://github.com/electron-userland/electron-builder)
|
||||
have already been updated to work with the new name while continuing to support
|
||||
the old name.
|
||||
|
||||
If you encounter any problems installing this new package, please let us know by
|
||||
opening an issue on the
|
||||
[electron-userland/electron-prebuilt](https://github.com/electron-userland/electron-prebuilt/issues)
|
||||
repository.
|
||||
|
||||
For any other issues with Electron,
|
||||
please use the [electron/electron](https://github.com/electron/electron/issues)
|
||||
repository.
|
||||
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
---
|
||||
title: Protocol Handler Vulnerability Fix
|
||||
author: zeke
|
||||
date: '2018-01-22'
|
||||
---
|
||||
|
||||
A remote code execution vulnerability has been discovered affecting
|
||||
Electron apps that use custom protocol handlers. This vulnerability has been
|
||||
assigned the CVE identifier [CVE-2018-1000006].
|
||||
|
||||
---
|
||||
|
||||
## Affected Platforms
|
||||
|
||||
Electron apps designed to run on Windows that register themselves as the default
|
||||
handler for a protocol, like `myapp://`, are vulnerable.
|
||||
|
||||
Such apps can be affected regardless of how the protocol is registered, e.g.
|
||||
using native code, the Windows registry, or Electron's
|
||||
[app.setAsDefaultProtocolClient] API.
|
||||
|
||||
macOS and Linux are **not vulnerable** to this issue.
|
||||
|
||||
## Mitigation
|
||||
|
||||
We've published new versions of Electron which include fixes for
|
||||
this vulnerability:
|
||||
[`1.8.2-beta.5`](https://github.com/electron/electron/releases/tag/v1.8.2-beta.5),
|
||||
[`1.7.12`](https://github.com/electron/electron/releases/tag/v1.7.12),
|
||||
and [`1.6.17`](https://github.com/electron/electron/releases/tag/v2.6.17).
|
||||
We urge all Electron developers to update their apps to the latest stable
|
||||
version immediately.
|
||||
|
||||
If for some reason you are unable to upgrade your Electron version,
|
||||
you can append `--` as the last argument when calling [app.setAsDefaultProtocolClient],
|
||||
which prevents Chromium from parsing further options.
|
||||
The double dash `--` signifies the end of command options,
|
||||
after which only positional parameters are accepted.
|
||||
|
||||
```js
|
||||
app.setAsDefaultProtocolClient(protocol, process.execPath, [
|
||||
'--your-switches-here',
|
||||
'--'
|
||||
])
|
||||
```
|
||||
|
||||
See the [app.setAsDefaultProtocolClient] API for more details.
|
||||
|
||||
To learn more about best practices for keeping your Electron apps secure,
|
||||
see our [security tutorial].
|
||||
|
||||
If you wish to report a vulnerability in Electron, email
|
||||
security@electronjs.org.
|
||||
|
||||
[security tutorial]: https://electronjs.org/docs/tutorial/security
|
||||
[app.setAsDefaultProtocolClient]: https://electronjs.org/docs/api/app#appsetasdefaultprotocolclientprotocol-path-args-macos-windows
|
||||
[CVE-2018-1000006]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000006
|
||||
156
blog/search.md
156
blog/search.md
|
|
@ -1,156 +0,0 @@
|
|||
---
|
||||
title: Search
|
||||
author:
|
||||
- echjordan
|
||||
- vanessayuenn
|
||||
- zeke
|
||||
date: '2018-06-21'
|
||||
---
|
||||
|
||||
The Electron website has a new search engine that delivers instant results for
|
||||
API docs, tutorials, Electron-related npm packages, and more.
|
||||
|
||||
<figure>
|
||||
<a href="https://electronjs.org/?query=resize" style="display: block; text-align: center;">
|
||||
<img class="screenshot" src="https://user-images.githubusercontent.com/2289/41683719-417ca80a-7490-11e8-9a52-fb145f4251ba.png" alt="Electron Search Screenshot"/>
|
||||
</a>
|
||||
</figure>
|
||||
|
||||
---
|
||||
|
||||
Learning a new technology or framework like Electron can be intimidating.
|
||||
Once you get past the [quick-start] phase, it can
|
||||
be difficult to learn best practices, find the right APIs, or discover the tools
|
||||
that will help you build the app of your dreams. We want the Electron website to
|
||||
be a better tool for finding the resources you need to build apps faster and
|
||||
more easily.
|
||||
|
||||
Visit any page on [electronjs.org](https://electronjs.org) and you'll find the
|
||||
new search input at the top of the page.
|
||||
|
||||
## The Search Engine
|
||||
|
||||
When we first set about adding search to the website, we rolled our own
|
||||
search engine using GraphQL as a backend. GraphQL was fun to work with and
|
||||
the search engine was performant, but we quickly realized that building a search
|
||||
engine is not a trivial task. Things like multi-word search and typo detection
|
||||
require a lot of work to get right. Rather than reinventing the wheel,
|
||||
we decided to use an existing search solution: [Algolia].
|
||||
|
||||
Algolia is a hosted search service that has quickly become the
|
||||
search engine of choice among popular open source projects like
|
||||
React, Vue, Bootstrap, Yarn, and [many others](https://community.algolia.com/docsearch/).
|
||||
|
||||
Here are some of the features that made Algolia a good fit for the Electron project:
|
||||
|
||||
- [InstantSearch.js](https://community.algolia.com/instantsearch.js) provides results as you type, usually in about 1ms.
|
||||
- [Typo tolerance](https://www.algolia.com/doc/guides/textual-relevance/typo-tolerance/) means you'll still get results even when you type [`widnow`].
|
||||
- [Advanced query syntax](https://www.algolia.com/doc/api-reference/api-parameters/advancedSyntax/) enables `"exact quoted matches"` and `-exclusion`.
|
||||
- [API clients](https://www.algolia.com/doc/api-client/javascript/getting-started/) are open source and with well-documented.
|
||||
- [Analytics](https://www.algolia.com/doc/guides/analytics/analytics-overview/) tell us what people are searching for most, as well as what they're searching for but not finding. This will give us valuable insight into how Electron's documentation can be improved.
|
||||
- Algolia is [free for open source projects](https://www.algolia.com/for-open-source).
|
||||
|
||||
## API Docs
|
||||
|
||||
Sometimes you know *what* you want to accomplish, but you don't know exactly
|
||||
*how* to do it. Electron has over 750 API methods, events, and properties.
|
||||
No human can easily remember all of them, but computers are good at this stuff.
|
||||
Using Electron's [JSON API docs](https://electronjs.org/blog/api-docs-json-schema),
|
||||
we indexed all of this data in Algolia, and now you can easily find
|
||||
the exact API you're looking for.
|
||||
|
||||
Trying to resize a window? Search for [`resize`] and jump straight to the method you need.
|
||||
|
||||
## Tutorials
|
||||
|
||||
Electron has an ever-growing collection of tutorials to complement its API
|
||||
documentation. Now you can more easily find tutorials on a given topic,
|
||||
right alongside related API documentation.
|
||||
|
||||
Looking for security best practices? Search for [`security`].
|
||||
|
||||
## npm Packages
|
||||
|
||||
There are now over 700,000 packages in the npm registry and it's not
|
||||
always easy to find the one you need. To make it easier to discover these modules,
|
||||
we've created [`electron-npm-packages`], a collection of the 3400+ modules in
|
||||
the registry that are built specifically for use with Electron.
|
||||
|
||||
The folks at [Libraries.io] have created [SourceRank],
|
||||
a system for scoring software projects based on a combination of metrics like
|
||||
code, community, documentation, and usage. We created a [`sourceranks`]
|
||||
module that includes the score of every module in the npm registry, and we
|
||||
use these scores to sort the package results.
|
||||
|
||||
Want alternatives to Electron's built-in IPC modules? Search for [`is:package ipc`].
|
||||
|
||||
## Electron Apps
|
||||
|
||||
It's [easy to index data with Algolia](https://github.com/electron/algolia-indices),
|
||||
so we added the existing apps list from [electron/apps](https://github.com/electron/apps).
|
||||
|
||||
Try a search for [`music`] or [`homebrew`].
|
||||
|
||||
## Filtering Results
|
||||
|
||||
If you've used GitHub's [code search](https://github.com/search) before,
|
||||
you're probably aware of its colon-separated key-value filters like
|
||||
`extension:js` or `user:defunkt`. We think this filtering technique is pretty
|
||||
powerful, so we've added an `is:` keyword to Electron's search that lets you
|
||||
filter results to only show a single type:
|
||||
|
||||
- [`is:api thumbnail`]
|
||||
- [`is:tutorial security`]
|
||||
- [`is:package ipc`]
|
||||
- [`is:app graphql`]
|
||||
|
||||
## Keyboard Navigation
|
||||
|
||||
People love keyboard shortcuts! The new search can be used without taking
|
||||
your fingers off the keyboard:
|
||||
|
||||
- <kbd>/</kbd> focuses the search input
|
||||
- <kbd>esc</kbd> focuses the search input and clears it
|
||||
- <kbd>down</kbd> moves to the next result
|
||||
- <kbd>up</kbd> moves to the previous result, or the search input
|
||||
- <kbd>enter</kbd> opens a result
|
||||
|
||||
We also open-sourced the [module](https://github.com/electron/search-with-your-keyboard/)
|
||||
that enables this keyboard interaction. It's designed for use with Algolia InstantSearch,
|
||||
but is generalized to enable compatibility with different search implementations.
|
||||
|
||||
## We want your feedback
|
||||
|
||||
If you encounter any issues with the new search tool, we want to hear about it!
|
||||
|
||||
The best way to submit your feedback is by filing an issue on GitHub in the
|
||||
appropriate repository:
|
||||
|
||||
- [electron/electronjs.org](https://github.com/electron/electronjs.org) is the Electron website. If you don't know where to file an issue, this your best bet.
|
||||
- [electron/algolia-indices](https://github.com/electron/algolia-indices) is where all the searchable Electron data is compiled.
|
||||
- [electron/search-with-your-keyboard](https://github.com/electron/search-with-your-keyboard) makes the search interface navigable by keyboard.
|
||||
- [algolia/instantsearch.js](https://github.com/algolia/instantsearch.js) is the browser-side client that enables find-as-you-type search.
|
||||
- [algolia/algoliasearch-client-javascript](https://github.com/algolia/algoliasearch-client-javascript) is the Node.js client for uploading data to Algolia's servers.
|
||||
|
||||
## Thanks
|
||||
|
||||
Special thanks to [Emily Jordan](https://github.com/echjordan)
|
||||
and [Vanessa Yuen](https://github.com/vanessayuenn)
|
||||
for building these new search capabilities, to [Libraries.io] for providing
|
||||
[SourceRank] scores, and to the team at Algolia for helping us get started. 🍹
|
||||
|
||||
[`electron-npm-packages`]: https://ghub.io/electron-npm-packages
|
||||
[`homebrew`]: https://electronjs.org/?query=homebrew
|
||||
[`is:api thumbnail`]: https://electronjs.org/?query=is%3Aapi%20thumbnail
|
||||
[`is:app graphql`]: https://electronjs.org/?query=is%3Aapp%20graphql
|
||||
[`is:package ipc`]: https://electronjs.org/?query=is%3Apackage%20ipc
|
||||
[`is:tutorial security`]: https://electronjs.org/?query=is%3Atutorial%20security
|
||||
[`music`]: https://electronjs.org/?query=music
|
||||
[`resize`]: https://electronjs.org/?query=resize
|
||||
[`security`]: https://electronjs.org/?query=security
|
||||
[`sourceranks`]: https://github.com/nice-registry/sourceranks
|
||||
[`widnow`]: https://electronjs.org/?query=widnow
|
||||
[Algolia]: https://algolia.com
|
||||
[Libraries.io]: https://libraries.io
|
||||
[quick-start]: https://github.com/electron/electron-quick-start
|
||||
[SourceRank]: https://docs.libraries.io/overview.html#sourcerank
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
---
|
||||
title: 'September 2016: New Apps'
|
||||
author: haacked
|
||||
date: '2016-10-06'
|
||||
---
|
||||
|
||||
Here are the new Electron apps and talks that were added to the site in September.
|
||||
|
||||
---
|
||||
|
||||
This site is updated with new [apps](https://electronjs.org/apps) and [meetups](https://electronjs.org/community) through [pull requests](https://github.com/electron/electronjs.org/pulls) from the community. You can [watch the repository](https://github.com/electron/electronjs.org) to get notifications of new additions or if you're not interested in _all_ of the site's changes, subscribe to the [blog RSS feed](https://electronjs.org/feed.xml).
|
||||
|
||||
If you've made an Electron app or host a meetup, make a [pull request](https://github.com/electron/electronjs.org) to add it to the site and it will make the next roundup.
|
||||
|
||||
### New Talks
|
||||
|
||||
In September, GitHub held its GitHub Universe conference billed as the event for people building the future of software. There were a couple of interesting Electron talks at the event.
|
||||
|
||||
* [Making Electron Development Simpler, More Pleasant, and More Productive](https://www.youtube.com/watch?v=Eqg_IqVeI5s) by Machisté Quintana, a Software Engineer at Slack.
|
||||
* [Electron: Desktop Apps with Web Languages](https://www.youtube.com/watch?v=FNHBfN8c32U) by Zeke Sikelianos, an Electron Developer at GitHub.
|
||||
|
||||
Also, if you happen to be in Paris on December 5, Zeke will be [giving an Electron talk at dotJS 2016](https://twitter.com/dotJS/status/783615732307333120).
|
||||
|
||||
### New Apps
|
||||
|
||||
| | | |
|
||||
|---|---|---|
|
||||
| <img src='/images/apps/pexels-icon.png' width='50'/> | [Pexels](https://www.pexels.com/pro/mac-and-windows-app/) | Search for completely free photos and copy them into your clipboard |
|
||||
| <img src='/images/apps/timestamp-icon.png' width='50'/> | [Timestamp](https://mzdr.github.io/timestamp/) | A better macOS menu bar clock with a customizable date/time display and a calendar |
|
||||
| <img src='/images/apps/harmony-icon.png' width='50'/> | [Harmony](http://getharmony.xyz/) | Music player compatible with Spotify, Soundcloud, Play Music and your local files |
|
||||
| <img src='/images/apps/uphone-icon.png' width='50'/> | [uPhone](http://www.integraccs.com) | WebRTC Desktop Phone |
|
||||
| <img src='/images/apps/sealtalk-icon.png' width='50'/> | [SealTalk](http://sealtalk.im) | Instant-messaging App powered by RongCloud IM Cloud Service and IM SDK |
|
||||
| <img src='/images/apps/infinity-icon.png' width='50'/> | [Infinity](https://ycosxapp.github.io) | An easy way to make presentation |
|
||||
| <img src='/images/apps/cycligent-git-tool-icon.png' width='50'/> | [Cycligent Git Tool](https://www.cycligent.com/git-tool) | Straightforward, graphic GUI for your Git projects |
|
||||
| <img src='/images/apps/foco-icon.png' width='50'/> | [Foco](https://github.com/akashnimare/foco) | Stay focused and boost productivity with Foco |
|
||||
| <img src='/images/apps/strawberry-icon.png' width='50'/> | [Strawberry](https://strawberrypos.com) | Win Diners for Life Know and serve them better with the all-in-one restaurant software suite. |
|
||||
| <img src='/images/apps/mixmax-icon.png' width='50'/> | [Mixmax](https://mixmax.com/download) | See every action on your emails in real-time Compose anywhere. |
|
||||
| <img src='/images/apps/firebase-admin-icon.png' width='50'/> | [Firebase Admin](https://firebaseadmin.com) | A Firebase data management tool |
|
||||
| <img src='/images/apps/anote-icon.png' width='50'/> | [ANote](https://github.com/AnotherNote/anote) | A Simple Friendly Markdown Note |
|
||||
| <img src='/images/apps/temps-icon.png' width='50'/> | [Temps](https://jackd248.github.io/temps/) | A simple but smart menubar weather app |
|
||||
| <img src='/images/apps/amium-icon.png' width='50'/> | [Amium](https://www.amium.com) | A work collaboration product that brings conversation to your files |
|
||||
| <img src='/images/apps/soube-icon.png' width='50'/> | [Soube](http://soube.diegomolina.cl) | Simple music player |
|
||||
| <img src='/images/apps/un-colored-icon.png' width='50'/> | [(Un)colored](https://n457.github.io/Uncolored/) | Next generation desktop rich content editor that saves documents with themes HTML & Markdown compatible. For Windows, OS X & Linux. |
|
||||
| <img src='/images/apps/quickcalc-icon.png' width='50'/> | [quickcalc](https://github.com/Cwoodall6/quickcalc) | Menubar Calculator |
|
||||
| <img src='/images/apps/forestpin-analytics-icon.png' width='50'/> | [Forestpin Analytics](http://forestpin.com/analytics) | Financial data analytics tool for businesses |
|
||||
| <img src='/images/apps/ling-icon.png' width='50'/> | [Ling](https://github.com/talhasch/ling) | REST Client |
|
||||
| <img src='/images/apps/shortexts-icon.png' width='50'/> | [Shortexts](http://shortexts.com/) | Shortcuts for texts you copy frequently, folders and emojis |
|
||||
| <img src='/images/apps/front-end-box-icon.png' width='50'/> | [Front-End Box](http://frontendbox.io) | Set of front-end-code generators |
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
---
|
||||
title: Electron Simple Samples
|
||||
author: zeke
|
||||
date: '2017-01-19'
|
||||
---
|
||||
|
||||
We recently hosted an Electron hackathon at GitHub HQ for members of [Hackbright Academy](https://hackbrightacademy.com), a coding school for women founded in San Francisco. To help attendees get a head start on their projects, our own [Kevin Sawicki](https://github.com/kevinsawicki) created a few sample Electron applications.
|
||||
|
||||
---
|
||||
|
||||
If you're new to Electron development or haven't yet tried it out, these
|
||||
sample applications are a great place to start. They are small, easy to read,
|
||||
and the code is heavily commented to explain how everything works.
|
||||
|
||||
To get started, clone this repository:
|
||||
|
||||
```sh
|
||||
git clone https://github.com/electron/simple-samples
|
||||
```
|
||||
|
||||
To run any of the apps below, change into the app's directory,
|
||||
install dependencies, then start:
|
||||
|
||||
```sh
|
||||
cd activity-monitor
|
||||
npm install
|
||||
npm start
|
||||
```
|
||||
|
||||
## Activity Monitor
|
||||
|
||||
Shows a doughnut chart of the CPU system, user, and idle activity time.
|
||||
|
||||
[](https://github.com/kevinsawicki/electron-samples/tree/master/activity-monitor)
|
||||
|
||||
## Hash
|
||||
|
||||
Shows the hash values of entered text using different algorithms.
|
||||
|
||||
[](https://github.com/kevinsawicki/electron-samples/tree/master/hash)
|
||||
|
||||
## Mirror
|
||||
|
||||
Plays a video of the computer's camera at a maximized size like looking into a mirror.
|
||||
Includes an optional rainbow filter effect that uses CSS animations.
|
||||
|
||||
## Prices
|
||||
|
||||
Shows the current price of oil, gold, and silver using the Yahoo Finance API.
|
||||
|
||||
[](https://github.com/kevinsawicki/electron-samples/tree/master/prices)
|
||||
|
||||
## URL
|
||||
|
||||
Loads a URL passed on the command line in a window.
|
||||
|
||||
## Other Resources
|
||||
|
||||
We hope these apps help you get started using Electron. Here are a handful other resources for learning more:
|
||||
|
||||
- [electron-quick-start](https://github.com/electron/electron-quick-start): A minimal Electron application boilerplate.
|
||||
- [Electron API Demos](https://github.com/electron/electron-api-demos): An interactive app that demonstrates the core features of the Electron API
|
||||
- [electronjs.org/docs/all](https://electronjs.org/docs/all/): All of the Electron documentation together on a single searchable page.
|
||||
- [hokein/electron-sample-apps](https://github.com/hokein/electron-sample-apps): Another collection of sample applications for Electron, compiled by Electron maintainer [Haojian Wu](https://github.com/hokein).
|
||||
- [awesome-electron](https://github.com/sindresorhus/awesome-electron) - A GitHub repository that collects the latest and greatest Electron-related tutorials, books, videos, etc.
|
||||
|
|
@ -1,141 +0,0 @@
|
|||
---
|
||||
title: Touch Bar Support
|
||||
author: kevinsawicki
|
||||
date: '2017-03-08'
|
||||
---
|
||||
|
||||
The Electron [1.6.3] beta release contains initial support for the macOS [Touch Bar].
|
||||
|
||||
---
|
||||
|
||||
The new Touch Bar API allows you to add buttons, labels, popovers, color
|
||||
pickers, sliders, and spacers. These elements can be dynamically updated and
|
||||
also emit events when they are interacted with.
|
||||
|
||||
This is the first release of this API so it will be evolving over the next
|
||||
few Electron releases. Please check out the release notes for further updates
|
||||
and open [issues](https://github.com/electron/electron/issues) for any problems
|
||||
or missing functionality.
|
||||
|
||||
You can install this version via `npm install electron@beta` and learn
|
||||
more about it in the [TouchBar](https://github.com/electron/electron/blob/master/docs/api/touch-bar.md)
|
||||
and [BrowserWindow](https://github.com/electron/electron/blob/master/docs/api/browser-window.md#winsettouchbartouchbar-macos)
|
||||
Electron docs.
|
||||
|
||||
Big thanks to [@MarshallOfSound](https://github.com/MarshallOfSound) for contributing this to Electron. :tada:
|
||||
|
||||
## Touch Bar Example
|
||||
|
||||
|
||||
|
||||
Below is an example of creating a simple slot machine game in the touch bar.
|
||||
It demonstrates how to create a touch bar, style the items, associate it with a
|
||||
window, handle button click events, and update the labels dynamically.
|
||||
|
||||
```js
|
||||
const {app, BrowserWindow, TouchBar} = require('electron')
|
||||
|
||||
const {TouchBarButton, TouchBarLabel, TouchBarSpacer} = TouchBar
|
||||
|
||||
let spinning = false
|
||||
|
||||
// Reel labels
|
||||
const reel1 = new TouchBarLabel()
|
||||
const reel2 = new TouchBarLabel()
|
||||
const reel3 = new TouchBarLabel()
|
||||
|
||||
// Spin result label
|
||||
const result = new TouchBarLabel()
|
||||
|
||||
// Spin button
|
||||
const spin = new TouchBarButton({
|
||||
label: '🎰 Spin',
|
||||
backgroundColor: '#7851A9',
|
||||
click: () => {
|
||||
// Ignore clicks if already spinning
|
||||
if (spinning) {
|
||||
return
|
||||
}
|
||||
|
||||
spinning = true
|
||||
result.label = ''
|
||||
|
||||
let timeout = 10
|
||||
const spinLength = 4 * 1000 // 4 seconds
|
||||
const startTime = Date.now()
|
||||
|
||||
const spinReels = () => {
|
||||
updateReels()
|
||||
|
||||
if ((Date.now() - startTime) >= spinLength) {
|
||||
finishSpin()
|
||||
} else {
|
||||
// Slow down a bit on each spin
|
||||
timeout *= 1.1
|
||||
setTimeout(spinReels, timeout)
|
||||
}
|
||||
}
|
||||
|
||||
spinReels()
|
||||
}
|
||||
})
|
||||
|
||||
const getRandomValue = () => {
|
||||
const values = ['🍒', '💎', '7️⃣', '🍊', '🔔', '⭐', '🍇', '🍀']
|
||||
return values[Math.floor(Math.random() * values.length)]
|
||||
}
|
||||
|
||||
const updateReels = () => {
|
||||
reel1.label = getRandomValue()
|
||||
reel2.label = getRandomValue()
|
||||
reel3.label = getRandomValue()
|
||||
}
|
||||
|
||||
const finishSpin = () => {
|
||||
const uniqueValues = new Set([reel1.label, reel2.label, reel3.label]).size
|
||||
if (uniqueValues === 1) {
|
||||
// All 3 values are the same
|
||||
result.label = '💰 Jackpot!'
|
||||
result.textColor = '#FDFF00'
|
||||
} else if (uniqueValues === 2) {
|
||||
// 2 values are the same
|
||||
result.label = '😍 Winner!'
|
||||
result.textColor = '#FDFF00'
|
||||
} else {
|
||||
// No values are the same
|
||||
result.label = '🙁 Spin Again'
|
||||
result.textColor = null
|
||||
}
|
||||
spinning = false
|
||||
}
|
||||
|
||||
const touchBar = new TouchBar([
|
||||
spin,
|
||||
new TouchBarSpacer({size: 'large'}),
|
||||
reel1,
|
||||
new TouchBarSpacer({size: 'small'}),
|
||||
reel2,
|
||||
new TouchBarSpacer({size: 'small'}),
|
||||
reel3,
|
||||
new TouchBarSpacer({size: 'large'}),
|
||||
result
|
||||
])
|
||||
|
||||
let window
|
||||
|
||||
app.once('ready', () => {
|
||||
window = new BrowserWindow({
|
||||
frame: false,
|
||||
titleBarStyle: 'hidden-inset',
|
||||
width: 200,
|
||||
height: 200,
|
||||
backgroundColor: '#000'
|
||||
})
|
||||
window.loadURL('about:blank')
|
||||
window.setTouchBar(touchBar)
|
||||
})
|
||||
```
|
||||
|
||||
[1.6.3]: https://github.com/electron/electron/releases/tag/v1.6.3
|
||||
[Touch Bar]: https://developer.apple.com/macos/touch-bar
|
||||
|
||||
|
|
@ -1,157 +0,0 @@
|
|||
---
|
||||
title: "Announcing TypeScript support in Electron"
|
||||
author: zeke
|
||||
date: '2017-06-01'
|
||||
---
|
||||
|
||||
The `electron` npm package now includes a TypeScript definition file that provides detailed annotations of the entire Electron API. These annotations can improve your Electron development
|
||||
experience **even if you're writing vanilla JavaScript**. Just
|
||||
`npm install electron` to get up-to-date Electron typings in your project.
|
||||
|
||||
---
|
||||
|
||||
TypeScript is an open-source programming language created by Microsoft. It's
|
||||
a superset of JavaScript that extends the language by adding support for
|
||||
static types. The TypeScript community has grown quickly in recent years,
|
||||
and TypeScript was ranked among the
|
||||
[most loved programming languages](https://stackoverflow.com/insights/survey/2017#technology-most-loved-dreaded-and-wanted-languages)
|
||||
in a recent Stack Overflow developer survey. TypeScript is described
|
||||
as "JavaScript that scales", and teams at
|
||||
[GitHub](https://githubengineering.com/how-four-native-developers-wrote-an-electron-app/),
|
||||
[Slack](https://slack.engineering/typescript-at-slack-a81307fa288d),
|
||||
and
|
||||
[Microsoft](https://github.com/Microsoft/vscode)
|
||||
are all using it to write scalable Electron apps that are used
|
||||
by millions of people.
|
||||
|
||||
TypeScript supports many of the newer language features in JavaScript like
|
||||
classes, object destructuring, and async/await, but its real differentiating
|
||||
feature is **type annotations**.
|
||||
Declaring the input and output datatypes expected by your program can
|
||||
[reduce bugs](https://slack.engineering/typescript-at-slack-a81307fa288d) by
|
||||
helping you find errors at compile time, and the annotations can also serve
|
||||
as a formal declaration of [how your program works](https://staltz.com/all-js-libraries-should-be-authored-in-typescript.html).
|
||||
|
||||
When libraries are written in vanilla Javascript, the types are often vaguely
|
||||
defined as an afterthought when writing documentation. Functions can often
|
||||
accept more types than what was documented, or a function can have invisible
|
||||
constraints that are not documented, which can lead to runtime errors.
|
||||
|
||||
TypeScript solves this problem with **definition files**.
|
||||
A TypeScript definition file describes all the functions of a library and its
|
||||
expected input and output types. When library authors bundle a TypeScript
|
||||
definition file with their published library, consumers of that library can
|
||||
[explore its API right inside their editor](https://code.visualstudio.com/docs/editor/intellisense)
|
||||
and start using it right away, often without needing to consult the library's
|
||||
documentation.
|
||||
|
||||
Many popular projects like
|
||||
[Angular](https://angularjs.org/),
|
||||
[Vue.js](http://vuejs.org/),
|
||||
[node-github](https://github.com/mikedeboer/node-github)
|
||||
(and now Electron!) compile their own definition file and bundle it with their
|
||||
published npm package. For projects that don't bundle their own definition file,
|
||||
there is
|
||||
[DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped),
|
||||
a third-party ecosystem of community-maintained definition files.
|
||||
|
||||
## Installation
|
||||
|
||||
Starting at version 1.6.10, every release of Electron includes its own
|
||||
TypeScript definition file. When you install the `electron` package from npm,
|
||||
the `electron.d.ts` file is bundled automatically with the
|
||||
installed package.
|
||||
|
||||
The [safest way](https://electronjs.org/docs/tutorial/electron-versioning/) to install Electron is using an exact version number:
|
||||
|
||||
```sh
|
||||
npm install electron --save-dev --save-exact
|
||||
```
|
||||
|
||||
Or if you're using [yarn](https://yarnpkg.com/lang/en/docs/migrating-from-npm/#toc-cli-commands-comparison):
|
||||
|
||||
```sh
|
||||
yarn add electron --dev --exact
|
||||
```
|
||||
|
||||
If you were already using third-party definitions like `@types/electron`
|
||||
and `@types/node`, you should remove them from your Electron project to prevent
|
||||
any collisions.
|
||||
|
||||
The definition file is derived from our
|
||||
[structured API documentation](https://electronjs.org/blog/2016/09/27/api-docs-json-schema),
|
||||
so it will always be consistent with [Electron's API documentation](https://electronjs.org/docs/api/).
|
||||
Just install `electron` and you'll always get TypeScript definitions that are
|
||||
up to date with the version of Electron you're using.
|
||||
|
||||
## Usage
|
||||
|
||||
For a summary of how to install and use Electron's new TypeScript annotations,
|
||||
watch this short demo screencast:
|
||||
|
||||
<iframe width="100%" height="420" src="https://www.youtube.com/embed/PJRag0rYQt8" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
If you're using [Visual Studio Code](https://code.visualstudio.com/), you've
|
||||
already got TypeScript support built in. There are also community-maintained
|
||||
plugins for
|
||||
[Atom](https://atom.io/packages/atom-typescript),
|
||||
[Sublime](https://github.com/Microsoft/TypeScript-Sublime-Plugin),
|
||||
[vim](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Editor-Support#vim),
|
||||
and
|
||||
[other editors](https://www.typescriptlang.org/index.html#download-links).
|
||||
|
||||
Once your editor is configured for TypeScript, you'll start to see more
|
||||
context-aware behavior like autocomplete suggestions, inline method reference,
|
||||
argument checking, and more.
|
||||
|
||||
<figure>
|
||||
<img src="https://cloud.githubusercontent.com/assets/2289/26128017/f6318c20-3a3f-11e7-9c2c-401a32d1f9fb.png" alt="Method autocompletion"/>
|
||||
<figcaption>Method autcompletion</figcaption>
|
||||
</figure>
|
||||
|
||||
<figure>
|
||||
<img src="https://cloud.githubusercontent.com/assets/2289/26128018/f6352600-3a3f-11e7-8d92-f0fb88ecc53e.png" alt="Method reference"/>
|
||||
<figcaption>Inline method reference</figcaption>
|
||||
</figure>
|
||||
|
||||
<figure>
|
||||
<img src="https://cloud.githubusercontent.com/assets/2289/26128021/f6b1ca0c-3a3f-11e7-8161-ce913268a9f0.png" alt="Argument checking"/>
|
||||
<figcaption>Argument checking</figcaption>
|
||||
</figure>
|
||||
|
||||
## Getting started with TypeScript
|
||||
|
||||
If you're new to TypeScript and want to learn more, this
|
||||
[introductory video from Microsoft](http://video.ch9.ms/ch9/4ae3/062c336d-9cf0-498f-ae9a-582b87954ae3/B881_mid.mp4)
|
||||
provides a nice overview of why the language was created, how it works,
|
||||
how to use it, and where it's headed.
|
||||
|
||||
There's also a
|
||||
[handbook](https://www.typescriptlang.org/docs/handbook/basic-types.html)
|
||||
and a
|
||||
[playground](https://www.typescriptlang.org/play/index.html)
|
||||
on the official TypeScript website.
|
||||
|
||||
Because TypeScript is a superset of JavaScript, your existing JavaScript code is
|
||||
already valid TypeScript. This means you can gradually transition an existing
|
||||
JavaScript project to TypeScript, sprinkling in new language features as needed.
|
||||
|
||||
## Thanks
|
||||
|
||||
This project would not have been possible without the help of Electron's
|
||||
community of open-source maintainers. Thanks to
|
||||
[Samuel Attard](https://github.com/MarshallOfSound),
|
||||
[Felix Rieseberg](https://github.com/felixrieseberg),
|
||||
[Birunthan Mohanathas](https://github.com/poiru),
|
||||
[Milan Burda](https://github.com/miniak),
|
||||
[Brendan Forster](https://github.com/shiftkey),
|
||||
and many others for their bug fixes, documentation improvements,
|
||||
and technical guidance.
|
||||
|
||||
## Support
|
||||
|
||||
If you encounter any issues using Electron's new TypeScript definition files,
|
||||
please file an issue on the
|
||||
[electron-typescript-definitions](https://github.com/electron/electron-typescript-definitions/issues) repository.
|
||||
|
||||
Happy TypeScripting!
|
||||
|
|
@ -1,93 +0,0 @@
|
|||
---
|
||||
title: Electron Userland
|
||||
author: zeke
|
||||
date: '2016-12-20'
|
||||
---
|
||||
|
||||
We've added a new [userland](https://electronjs.org/userland) section to
|
||||
the Electron website to help users discover the people, packages, and apps that make
|
||||
up our flourishing open-source ecosystem.
|
||||
|
||||
---
|
||||
|
||||
[](https://electronjs.org/userland)
|
||||
|
||||
## Origins of Userland
|
||||
|
||||
Userland is where people in software communities come together to share tools and ideas.
|
||||
The term originated in the Unix community, where it referred to
|
||||
any program that ran outside of the kernel, but today it means something more.
|
||||
When people in today's Javascript community refer to userland, they're usually
|
||||
talking about the [npm package registry](http://npm.im). This is where the majority of experimentation and
|
||||
innovation happens, while Node and the JavaScript language (like the Unix kernel) retain
|
||||
a relatively small and stable set of core features.
|
||||
|
||||
## Node and Electron
|
||||
|
||||
Like Node, Electron has a small set of core APIs. These provide
|
||||
the basic features needed for developing multi-platform desktop applications.
|
||||
This design philosophy allows Electron to remain a flexible tool without being
|
||||
overly prescriptive about how it should be used.
|
||||
|
||||
Userland is the counterpart to "core", enabling users to
|
||||
create and share tools that extend Electron's functionality.
|
||||
|
||||
## Collecting data
|
||||
|
||||
To better understand the trends in our ecosystem, we
|
||||
analyzed metadata from 15,000 public GitHub repositories
|
||||
that depend on `electron` or `electron-prebuilt`
|
||||
|
||||
We used the
|
||||
[GitHub API](https://developer.github.com/v3/),
|
||||
the
|
||||
[libraries.io API](https://libraries.io/api),
|
||||
and the npm registry to gather info about dependencies,
|
||||
development dependencies, dependents, package authors,
|
||||
repo contributors, download counts, fork counts, stargazer
|
||||
counts, etc.
|
||||
|
||||
We then used this data to generate the following reports:
|
||||
|
||||
- [App Development Dependencies](https://electronjs.org/userland/dev_dependencies): Packages most often listed as `devDependencies` in Electron apps.
|
||||
- [GitHub Contributors](https://electronjs.org/userland/github_contributors): GitHub users who have contributed to numerous Electron-related GitHub repositories.
|
||||
- [Package Dependencies](https://electronjs.org/userland/package_dependencies): Electron-related npm packages that are frequently depended on by other npm packages.
|
||||
- [Starred Apps](https://electronjs.org/userland/starred_apps): Electron apps (that are not npm packages) with numerous stargazers.
|
||||
- [Most Downloaded Packages](https://electronjs.org/userland/most_downloaded_packages): Electron-related npm packages that are downloaded a lot.
|
||||
- [App Dependencies](https://electronjs.org/userland/dependencies): Packages most often listed as `dependencies` in Electron apps.
|
||||
- [Package Authors](https://electronjs.org/userland/package_authors): The most prolific authors of Electron-related npm packages.
|
||||
|
||||
## Filtering Results
|
||||
|
||||
Reports like
|
||||
[app dependencies](https://electronjs.org/userland/dependencies) and
|
||||
[starred apps](https://electronjs.org/userland/starred_apps)
|
||||
which list packages, apps, and repos have a text input that can be used to
|
||||
filter the results.
|
||||
|
||||
As you type into this input, the URL of the page is updated dynamically. This
|
||||
allows you to copy a URL representing a particular slice of userland data,
|
||||
then share it with others.
|
||||
|
||||
[
|
||||
](https://electronjs.org/userland/dev_dependencies?q=babel%20preset)
|
||||
|
||||
## More to come
|
||||
|
||||
This first set of reports is just the beginning. We will continue to collect
|
||||
data about how the community is building Electron, and will be adding
|
||||
new reports to the website.
|
||||
|
||||
All of the tools used to collect and display this data are open-source:
|
||||
|
||||
- [electron/electronjs.org](https://github.com/electron/electron.atom): The Electron website.
|
||||
- [electron/electron-userland-reports](https://github.com/electron/electron-userland-reports): Slices of data about packages, repos, and users in Electron userland.
|
||||
- [electron/repos-using-electron](https://github.com/electron/repos-using-electron): All public repositories on GitHub that depend on `electron` or `electron-prebuilt`
|
||||
- [electron/electron-npm-packages](https://github.com/zeke/electron-npm-packages): All npm packages that mention `electron` in their `package.json` file.
|
||||
|
||||
If you have ideas about how to improve these reports, please let us know
|
||||
[opening an issue on the website repository](https://github.com/electron/electronjs.org/issues/new)
|
||||
or any of the above-mentioned repos.
|
||||
|
||||
Thanks to you, the Electron community, for making userland what it is today!
|
||||
|
||||
|
|
@ -1,97 +0,0 @@
|
|||
---
|
||||
title: 'Project of the Week: Voltra'
|
||||
author:
|
||||
- '0x00A'
|
||||
- aprileelcich
|
||||
- zeke
|
||||
date: '2017-03-07'
|
||||
---
|
||||
|
||||
This week we met with [Aprile Elcich](https://twitter.com/aprileelcich) and
|
||||
[Paolo Fragomeni](https://twitter.com/0x00A) to talk about Voltra, an
|
||||
Electron-powered music player.
|
||||
|
||||
---
|
||||
|
||||
## What is Voltra?
|
||||
|
||||
[Voltra](https://voltra.co/) is a music player for people who want to own their music. It’s also a store where you can discover and buy new music based on what you already own. It’s ad-free, cross-platform for desktop and mobile. It also doesn’t spy on you.
|
||||
|
||||
[](https://voltra.co/)
|
||||
|
||||
## Who is Voltra for?
|
||||
|
||||
Anyone who listens to music.
|
||||
|
||||
## What motivated you to create Voltra?
|
||||
|
||||
Radio has has always had a big share of listeners. It’s moving off the airwaves and onto the Internet. Now you can rent music on demand — it’s a radio revival! A lot of new products and services have emerged because of this, but streaming radio still leaves someone else in control of your music and how you experience it.
|
||||
|
||||
We wanted a product that was entirely focused on music you own. Something that made it easy to discover and buy new music directly from artists or labels.
|
||||
|
||||
## Is there a free version?
|
||||
|
||||
The desktop player is completely free. [Selling your music is also free!](https://voltra.co/artists) We are not ad-supported.
|
||||
|
||||
Since the app is free, we may open source it later on. Right now we don’t have the bandwidth to manage that. We also have very specific ideas for features and the direction we want to take things. We have an active beta community and we take our feedback to heart.
|
||||
|
||||
## How do you make money?
|
||||
|
||||
We have premium features!
|
||||
|
||||
Our [Voltra Audio Archive](https://voltra.co/premium/) is a cloud-backup service designed specifically for music. We don’t compress or share data blocks. Your music collection is physically backed up for you.
|
||||
|
||||
For artists and labels, our [Pro Membership](https://voltra.co/artists/pro) offers tools to help them reach more relevant audiences, such as analytics and professional artist webpages.
|
||||
|
||||
## What makes Voltra different?
|
||||
|
||||
Design and usability are incredibly important to us. We want to give listeners a distraction-free listening experience! There are a some interesting music players and stores out there. But many of them are more advanced and harder to use than their creators realize. We want to make Voltra accessible to as many people as possible.
|
||||
|
||||
We also don't take a cut from the artist or the label. That’s a key differentiator for us. It’s really important because it lowers the barrier for artists to get their music to market.
|
||||
|
||||
## What are some design & technical decisions you made?
|
||||
|
||||
While designing Voltra, we considered UI conventions from native apps and the web, we also thought a lot about what we could remove. We have an active private beta group who have given us critical feedback over the last few months.
|
||||
|
||||
We found that album art and photography are really important to people. Many players are just lists of files. One of the cool things about owning physical albums is the album art, and we wanted to put emphasis on this in the Voltra desktop app.
|
||||
|
||||
[](https://voltra.co/)
|
||||
|
||||
We also made sure not to mess with people's files. We use file watching so you can put your files wherever you want, and we don't rename them or move them for you. We have an embedded database to track the state of the watched directories so that we can track what's new, even when the process isn't running.
|
||||
|
||||
## What are some challenges you've faced while building Voltra?
|
||||
|
||||
We spend a lot of time focused on performance. We started with frameworks but moved to vanilla Javascript. In our experience, the generalized abstractions they provide outweigh the performance penalties and ceremony that they introduce.
|
||||
|
||||
We handle very large collections pretty well at this point. Large collections means possibly tens of thousands of images! Having Node.js’ file system module directly available from the render process made it really easy to lazy load and unload lots of images super quickly based on DOM events.
|
||||
|
||||
In general *[setImmediate]* and *[requestIdleCallback]* have been super important tools for performing lots of processing while keeping the UI responsive. More specifically, distributing CPU-bound tasks into separate processes really helps to keep the user interface responsive. For example, we moved the actual audio context into a separate process, communicating with it over [IPC] to avoid potential interruptions from a busy UI.
|
||||
|
||||
## Why did you choose to build Voltra on Electron?
|
||||
|
||||
The browser’s sandbox is too restricted for our app. But we are also developing a web player. So it’s a huge win that we can share almost 100% of the code between the two implementations.
|
||||
|
||||
We actually started by building a native app with Swift. The main problem we found was that we were reinventing a lot of things. The web has the world’s largest open source eco-system. So we pretty quickly switched to Electron.
|
||||
|
||||
Also, and most importantly, with Electron you develop once and it should Just Work™ on all the major platforms. It’s not guaranteed, but the cost of coding natively for each platform definitely outweighs any other costs that electron introduces.
|
||||
|
||||
## What are your favorite things about Electron?
|
||||
|
||||
**GTD!**: Having Node.js’ networking stack and Chromium’s presentation layer packaged together is a recipe for getting things done.
|
||||
|
||||
**Competency**: It’s just the web stack, so literally our whole team is involved in actually building the product.
|
||||
|
||||
**Community**: There is a highly organized community that knows how to communicate really well! We feel pretty great about developing with support like that.
|
||||
|
||||
## In what areas could Electron be improved?
|
||||
|
||||
We would like to see Electron endorse a single packager. The packager is as important to Electron what the package manager is to Node. There are multiple packagers in user-land, each with interesting features but each with bugs. Consensus by the community would help to direct the energy being spent by contributors.
|
||||
|
||||
## What's coming next?
|
||||
|
||||
We‘re currently developing a mobile app, and working with artists and labels to add their music to the Voltra shop. Hey! If you’re an artist or label, [sign up now](https://admin.voltra.co/signup)! We plan on opening up the shop when we reach our goal of 10 million tracks.
|
||||
|
||||
[setImmediate]: https://developer.mozilla.org/en-US/docs/Web/API/Window/setImmediate
|
||||
[requestIdleCallback]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
|
||||
[IPC]: https://electronjs.org/docs/glossary/#ipc
|
||||
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
---
|
||||
title: WebPreferences Vulnerability Fix
|
||||
author: ckerr
|
||||
date: '2018-08-22'
|
||||
---
|
||||
|
||||
A remote code execution vulnerability has been discovered affecting apps with the ability to open nested child windows on Electron versions (3.0.0-beta.6, 2.0.7, 1.8.7, and 1.7.15). This vulnerability has been assigned the CVE identifier [CVE-2018-15685].
|
||||
|
||||
---
|
||||
|
||||
## Affected Platforms
|
||||
|
||||
You are impacted if:
|
||||
|
||||
1. You embed _any_ remote user content, even in a sandbox
|
||||
2. You accept user input with any XSS vulnerabilities
|
||||
|
||||
_Details_
|
||||
|
||||
You are impacted if any user code runs inside an `iframe` / can create an `iframe`. Given the possibility of an XSS vulnerability it can be assumed that most apps are vulnerable to this case.
|
||||
|
||||
You are also impacted if you open any of your windows with the `nativeWindowOpen: true` or `sandbox: true` option. Although this vulnerability also requires an XSS vulnerability to exist in your app, you should still apply one of the mitigations below if you use either of these options.
|
||||
|
||||
## Mitigation
|
||||
|
||||
We've published new versions of Electron which include fixes for this vulnerability: [`3.0.0-beta.7`](https://github.com/electron/electron/releases/tag/v3.0.0-beta.7), [`2.0.8`](https://github.com/electron/electron/releases/tag/v2.0.8), [`1.8.8`](https://github.com/electron/electron/releases/tag/v1.8.8), and [`1.7.16`](https://github.com/electron/electron/releases/tag/v1.7.16). We urge all Electron developers to update their apps to the latest stable version immediately.
|
||||
|
||||
If for some reason you are unable to upgrade your Electron version, you can protect your app by blanket-calling `event.preventDefault()` on the `new-window` event for all `webContents`'. If you don't use `window.open` or any child windows at all then this is also a valid mitigation for your app.
|
||||
|
||||
```javascript
|
||||
mainWindow.webContents.on('new-window', e => e.preventDefault())
|
||||
```
|
||||
|
||||
If you rely on the ability of your child windows to make grandchild windows, then a third mitigation strategy is to use the following code on your top level window:
|
||||
|
||||
```javascript
|
||||
const enforceInheritance = (topWebContents) => {
|
||||
const handle = (webContents) => {
|
||||
webContents.on('new-window', (event, url, frameName, disposition, options) => {
|
||||
if (!options.webPreferences) {
|
||||
options.webPreferences = {}
|
||||
}
|
||||
Object.assign(options.webPreferences, topWebContents.getLastWebPreferences())
|
||||
if (options.webContents) {
|
||||
handle(options.webContents)
|
||||
}
|
||||
})
|
||||
}
|
||||
handle(topWebContents)
|
||||
}
|
||||
|
||||
enforceInheritance(mainWindow.webContents)
|
||||
```
|
||||
|
||||
This code will manually enforce that the top level windows `webPreferences` is manually applied to all child windows infinitely deep.
|
||||
|
||||
## Further Information
|
||||
|
||||
This vulnerability was found and reported responsibly to the Electron project by [Matt Austin](https://twitter.com/mattaustin) of [Contrast Security](https://www.contrastsecurity.com/security-influencers/cve-2018-15685).
|
||||
|
||||
To learn more about best practices for keeping your Electron apps secure, see our [security tutorial].
|
||||
|
||||
If you wish to report a vulnerability in Electron, email security@electronjs.org.
|
||||
|
||||
[security tutorial]: https://electronjs.org/docs/tutorial/security
|
||||
[CVE-2018-15685]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15685
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
---
|
||||
title: Website Hiccups
|
||||
author: zeke
|
||||
date: '2018-02-12'
|
||||
---
|
||||
|
||||
Last week the [electronjs.org](https://electronjs.org) site had a few minutes
|
||||
of downtime. If you were affected by these brief outages, we're sorry
|
||||
for the inconvenience. After a bit of investigation today, we've diagnosed
|
||||
the root cause and have deployed a [fix](https://github.com/electron/electronjs.org/pull/1076).
|
||||
|
||||
---
|
||||
|
||||
To prevent this kind of downtime in the future, we've enabled
|
||||
[Heroku threshold alerts](https://devcenter.heroku.com/articles/metrics#threshold-alerting)
|
||||
on our app. Any time our web server accumulates failed requests or slow responses beyond a certain threshold, our team will be notified so we can
|
||||
address the problem quickly.
|
||||
|
||||
## Offline Docs in Every Language
|
||||
|
||||
The next time you're developing an Electron app on a plane or in a subterranean
|
||||
coffee shop, you might want to have a copy of the docs for offline reference.
|
||||
Fortunately, Electron's docs are available as Markdown files in over 20
|
||||
languages.
|
||||
|
||||
```sh
|
||||
git clone https://github.com/electron/electron-i18n
|
||||
ls electron-i18n/content
|
||||
```
|
||||
|
||||
## Offline Docs with a GUI
|
||||
|
||||
[devdocs.io/electron](https://devdocs.io/electron/) is a handy website that
|
||||
stores docs for offline use, not just for Electron but many other projects like
|
||||
JavaScript, TypeScript, Node.js, React, Angular, and many others. And of course
|
||||
there's an Electron app for that, too.
|
||||
Check out [devdocs-app](https://electronjs.org/apps/devdocs-app)
|
||||
on the Electron site.
|
||||
|
||||
[](https://electronjs.org/apps/devdocs-app)
|
||||
|
||||
If you like to install apps without using your mouse or trackpad, give
|
||||
[Electron Forge](https://electronforge.io/)'s `install` command a try:
|
||||
|
||||
```sh
|
||||
npx electron-forge install egoist/devdocs-app
|
||||
```
|
||||
|
|
@ -1,139 +0,0 @@
|
|||
---
|
||||
title: 'Project of the Week: WebTorrent'
|
||||
author:
|
||||
- feross
|
||||
- zeke
|
||||
date: '2017-03-14'
|
||||
---
|
||||
|
||||
This week we caught up with [@feross](https://github.com/feross) and [@dcposch](https://github.com/dcposch) to talk about WebTorrent, the web-powered torrent client that connects users together to form a distributed, decentralized browser-to-browser network.
|
||||
|
||||
---
|
||||
|
||||
## What is WebTorrent?
|
||||
|
||||
[WebTorrent](https://webtorrent.io) is the first torrent client that works in the browser. It's written completely in JavaScript and it can use WebRTC for peer-to-peer transport. No browser plugin, extension, or installation is required.
|
||||
|
||||
Using open web standards, WebTorrent connects website users together to form a distributed, decentralized browser-to-browser network for efficient file transfer.
|
||||
|
||||
You can see a demo of WebTorrent in action here: [webtorrent.io](https://webtorrent.io/).
|
||||
|
||||
<a href="https://webtorrent.io/">
|
||||
<img alt="webtorrent homepage" src="https://cloud.githubusercontent.com/assets/2289/23912149/1543d2ce-089c-11e7-8519-613740c82b47.jpg"/>
|
||||
</a>
|
||||
|
||||
## Why is this cool?
|
||||
|
||||
Imagine a video site like YouTube, but where visitors help to host the site's content. The more people that use a WebTorrent-powered website, the faster and more resilient it becomes.
|
||||
|
||||
Browser-to-browser communication cuts out the middle-man and lets people communicate on their own terms. No more client/server – just a network of peers, all equal. WebTorrent is the first step in the journey to re-decentralize the Web.
|
||||
|
||||
## Where does Electron come into the picture?
|
||||
|
||||
About one year ago, we decided to build [WebTorrent Desktop](https://webtorrent.io/desktop/), a version of WebTorrent that runs as a desktop app.
|
||||
|
||||
[](https://webtorrent.io/desktop/)
|
||||
|
||||
We created WebTorrent Desktop for three reasons:
|
||||
|
||||
1. We wanted a clean, lightweight, ad-free, open source torrent app
|
||||
2. We wanted a torrent app with good streaming support
|
||||
3. We need a "hybrid client" that connects the BitTorrent and WebTorrent networks
|
||||
|
||||
## If we can already download torrents in my web browser, why a desktop app?
|
||||
|
||||
First, a bit of background on the design of WebTorrent.
|
||||
|
||||
<a href="https://webtorrent.io/desktop/">
|
||||
<img alt="webtorrent desktop logo" src="https://cloud.githubusercontent.com/assets/2289/23912151/154657e2-089c-11e7-9889-6914ce71ebc9.png" width="200" align="right"/>
|
||||
</a>
|
||||
|
||||
In the early days, BitTorrent used TCP as its transport protocol. Later, uTP came along promising better performance and additional advantages over TCP. Every mainstream torrent client eventually adopted uTP, and today you can use BitTorrent over either protocol. The WebRTC protocol is the next logical step. It brings the promise of interoperability with web browsers – one giant P2P network made up of all desktop BitTorrent clients and millions of web browsers.
|
||||
|
||||
“Web peers” (torrent peers that run in a web browser) make the BitTorrent network stronger by adding millions of new peers, and spreading BitTorrent to dozens of new use cases. WebTorrent follows the BitTorrent spec as closely as possible, to make it easy for existing BitTorrent clients to add support for WebTorrent.
|
||||
|
||||
Some torrent apps like [Vuze](https://www.vuze.com/) already support web peers, but we didn't want to wait around for the rest to add support. **So basically, WebTorrent Desktop was our way to speed up the adoption of the WebTorrent protocol.** By making an awesome torrent app that people really want to use, we increase the number of peers in the network that can share torrents with web peers (i.e. users on websites).
|
||||
|
||||
## What are some interesting use cases for torrents beyond what people already know they can do?
|
||||
|
||||
One of the most exciting uses for WebTorrent is peer-assisted delivery. Non-profit projects like [Wikipedia](https://www.wikipedia.org/) and the [Internet Archive](https://archive.org/) could reduce bandwidth and hosting costs by letting visitors chip in. Popular content can be served browser-to-browser, quickly and cheaply. Rarely-accessed content can be served reliably over HTTP from the origin server.
|
||||
|
||||
The Internet Archive actually already updated their torrent files so they work great with WebTorrent. So if you want to embed Internet Archive content on your site, you can do it in a way that reduces hosting costs for the Archive, allowing them to devote more money to actually archiving the web!
|
||||
|
||||
There are also exciting business use cases, from CDNs to app delivery over P2P.
|
||||
|
||||
## What are some of your favorite projects that use WebTorrent?
|
||||
|
||||
|
||||
|
||||
The coolest thing built with WebTorrent, hands down, is probably [Gaia 3D Star Map](http://charliehoey.com/threejs-demos/gaia_dr1.html). It's a slick 3D interactive simulation of the Milky Way. The data loads from a torrent, right in your browser. It's awe-inspiring to fly through our star system and realize just how little we humans are compared to the vastness of our universe.
|
||||
|
||||
You can read about how this was made in [Torrenting The Galaxy](https://medium.com/@flimshaw/torrenting-the-galaxy-extracting-2-million-3d-stars-from-180gb-of-csvs-457ff70c0f93), a blog post where the author, Charlie Hoey, explains how he built the star map with WebGL and WebTorrent.
|
||||
|
||||
<a href="https://brave.com/">
|
||||
<img alt="brave logo" src="https://cloud.githubusercontent.com/assets/2289/23912147/1542ad4a-089c-11e7-8106-15c8e34298a9.png" width="150" align="left"/>
|
||||
</a>
|
||||
|
||||
We're also huge fans of [Brave](https://brave.com/). Brave is a browser that automatically blocks ads and trackers to make the web faster and safer. Brave recently added torrent support, so you can [view traditional torrents without using a separate app](https://torrentfreak.com/brave-a-privacy-focused-browser-with-built-in-torrent-streaming-170219/). That feature is powered by WebTorrent.
|
||||
|
||||
So, just like how most browsers can render PDF files, Brave can render magnet links and torrent files. They're just another type of content that the browser natively supports.
|
||||
|
||||
One of the co-founders of Brave is actually Brendan Eich, the creator of JavaScript, the language we wrote WebTorrent in, so we think it's pretty cool that Brave chose to integrate WebTorrent.
|
||||
|
||||
## Why did you choose to build WebTorrent Desktop on Electron?
|
||||
|
||||
<a href="https://webtorrent.io/desktop/">
|
||||
<img alt="WebTorrent Desktop main window" src="https://cloud.githubusercontent.com/assets/2289/23912150/15444542-089c-11e7-91ab-7fe3f1e5ee43.jpg" align="right" width="450"/>
|
||||
</a>
|
||||
|
||||
There is a meme that Electron apps are "bloated" because they include the entire Chrome content module in every app. In some cases, this is partially true (an Electron app installer is usually ~40MB, where an OS-specific app installer is usually ~20MB).
|
||||
|
||||
However, in the case of WebTorrent Desktop, we use nearly every Electron feature, and many dozens of Chrome features in the course of normal operation. If we wanted to implement these features from scratch for each platform, it would have taken months or years longer to build our app, or we would have only been able to release for a single platform.
|
||||
|
||||
Just to get an idea, we use Electron's [dock integration](https://electronjs.org/docs/api/app/#appdockbouncetype-macos) (to show download progress), [menu bar integration](https://electronjs.org/docs/api/menu) (to run in the background), [protocol handler registration](https://electronjs.org/docs/api/app/#appsetasdefaultprotocolclientprotocol-path-args-macos-windows) (to open magnet links), [power save blocker](https://electronjs.org/docs/api/power-save-blocker/) (to prevent sleep during video playback), and [automatic updater](https://electronjs.org/docs/api/auto-updater). As for Chrome features, we use plenty: the `<video>` tag (to play many different video formats), the `<track>` tag (for closed captions support), drag-and-drop support, and WebRTC (which is non-trivial to use in a native app).
|
||||
|
||||
Not to mention: our torrent engine is written in JavaScript and assumes the existence of lots of Node APIs, but especially `require('net')` and `require('dgram')` for TCP and UDP socket support.
|
||||
|
||||
Basically, Electron is just what we needed and had the exact set of features we needed to ship a solid, polished app in record time.
|
||||
|
||||
## What are your favorite things about Electron?
|
||||
|
||||
The WebTorrent library has been in development as an open source side project for two years. **We made WebTorrent Desktop in four weeks.** Electron is the primary reason that we were able to build and ship our app so quickly.
|
||||
|
||||
Just as Node.js made server programming accessible to a generation of jQuery-using front-end programmers, Electron makes native app development accessible to anyone familiar with Web or Node.js development. Electron is extremely empowering.
|
||||
|
||||
## Do the website and the Desktop client share code?
|
||||
|
||||
Yes, the [`webtorrent` npm package](https://npmjs.com/package/webtorrent) works in Node.js, in the browser, and in Electron. The exact same code can run in all environments – this is the beauty of JavaScript. It's today's universal runtime. Java Applets promised "Write Once, Run Anywhere" apps, but that vision never really materialized for a number of reasons. Electron, more than any other platform, actually gets pretty darn close to that ideal.
|
||||
|
||||
## What are some challenges you've faced while building WebTorrent?
|
||||
|
||||
In early versions of the app, we struggled to make the UI performant. We put the torrent engine in the same renderer process that draws the main app window which, predictably, led to slowness anytime there was intense CPU activity from the torrent engine (like verifying the torrent pieces received from peers).
|
||||
|
||||
We fixed this by moving the torrent engine to a second, invisible renderer process that we communicate with over [IPC](https://electronjs.org/docs/api/ipc-main/). This way, if that process briefly uses a lot of CPU, the UI thread will be unaffected. Buttery-smooth scrolling and animations are so satisfying.
|
||||
|
||||
Note: we had to put the torrent engine in a renderer process, instead of a "main" process, because we need access to WebRTC (which is only available in the renderer.)
|
||||
|
||||
## In what areas should Electron be improved?
|
||||
|
||||
One thing we'd love to see is better documentation about how to build and ship production-ready apps, especially around tricky subjects like code signing and auto-updating. We had to learn about best practices by digging into source code and asking around on Twitter!
|
||||
|
||||
## Is WebTorrent Desktop done? If not, what's coming next?
|
||||
|
||||
We think the current version of WebTorrent Desktop is excellent, but there's always room for improvement. We're currently working on improving polish, performance, subtitle support, and video codec support.
|
||||
|
||||
If you're interested in getting involved in the project, check out [our GitHub page](https://github.com/feross/webtorrent-desktop)!
|
||||
|
||||
## Any Electron development tips that might be useful to other developers?
|
||||
|
||||
[Feross](http://feross.org/), one of the WebTorrent Desktop contributors, recently gave a talk *"Real world Electron: Building Cross-platform desktop apps with JavaScript"* at NodeConf Argentina that contains useful tips for releasing a polished Electron app. The talk is especially useful if you're at the stage where you have a basic working app and you're trying to take it to the next level of polish and professionalism.
|
||||
|
||||
[Watch here](https://www.youtube.com/watch?v=YLExGgEnbFY):
|
||||
|
||||
<iframe width="100%" height="360" src="https://www.youtube.com/embed/YLExGgEnbFY?rel=0" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
[Slides here](https://speakerdeck.com/feross/real-world-electron):
|
||||
|
||||
<script async class="speakerdeck-embed" data-id="5aae08bb7c5b4dbd89060cff11bb1300" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
|
||||
|
||||
[DC](https://dcpos.ch/), another WebTorrent contributor, wrote [a checklist of things you can do](https://blog.dcpos.ch/how-to-make-your-electron-app-sexy) to make your app feel polished and native. It comes with code examples and covers things like macOS dock integration, drag-and-drop, desktop notifications, and making sure your app loads quickly.
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
---
|
||||
title: Webview Vulnerability Fix
|
||||
author: ckerr
|
||||
date: '2018-03-21'
|
||||
---
|
||||
|
||||
A vulnerability has been discovered which allows Node.js integration to be re-enabled in some Electron applications that disable it. This vulnerability has been assigned the CVE identifier [CVE-2018-1000136](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000136).
|
||||
|
||||
---
|
||||
|
||||
## Affected Applications
|
||||
|
||||
An application is affected if *all* of the following are true:
|
||||
|
||||
1. Runs on Electron 1.7, 1.8, or a 2.0.0-beta
|
||||
2. Allows execution of arbitrary remote code
|
||||
3. Disables Node.js integration
|
||||
4. Does not explicitly declare `webviewTag: false` in its webPreferences
|
||||
5. Does not enable the `nativeWindowOption` option
|
||||
6. Does not intercept `new-window` events and manually override `event.newGuest` without using the supplied options tag
|
||||
|
||||
Although this appears to be a minority of Electron applicatons, we encourage all applications to be upgraded as a precaution.
|
||||
|
||||
## Mitigation
|
||||
|
||||
This vulnerability is fixed in today's [1.7.13](https://github.com/electron/electron/releases/tag/v1.7.13), [1.8.4](https://github.com/electron/electron/releases/tag/v1.8.4), and [2.0.0-beta.5](https://github.com/electron/electron/releases/tag/v2.0.0-beta.5) releases.
|
||||
|
||||
Developers who are unable to upgrade their application's Electron version can mitigate the vulnerability with the following code:
|
||||
|
||||
```js
|
||||
app.on('web-contents-created', (event, win) => {
|
||||
win.on('new-window', (event, newURL, frameName, disposition,
|
||||
options, additionalFeatures) => {
|
||||
if (!options.webPreferences) options.webPreferences = {};
|
||||
options.webPreferences.nodeIntegration = false;
|
||||
options.webPreferences.nodeIntegrationInWorker = false;
|
||||
options.webPreferences.webviewTag = false;
|
||||
delete options.webPreferences.preload;
|
||||
})
|
||||
})
|
||||
|
||||
// and *IF* you don't use WebViews at all,
|
||||
// you might also want
|
||||
app.on('web-contents-created', (event, win) => {
|
||||
win.on('will-attach-webview', (event, webPreferences, params) => {
|
||||
event.preventDefault();
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Further Information
|
||||
|
||||
This vulnerability was found and reported responsibly to the Electron project by Brendan Scarvell of [Trustwave SpiderLabs](https://www.trustwave.com/Company/SpiderLabs/).
|
||||
|
||||
To learn more about best practices for keeping your Electron apps secure, see our [security tutorial](https://electronjs.org/docs/tutorial/security).
|
||||
|
||||
To report a vulnerability in Electron, please email security@electronjs.org.
|
||||
|
||||
Please join our [email list](https://groups.google.com/forum/#!forum/electronjs) to receive updates about releases and security updates.
|
||||
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
---
|
||||
title: BrowserView window.open() Vulnerability Fix
|
||||
author: ckerr
|
||||
date: '2019-02-03'
|
||||
---
|
||||
|
||||
A code vulnerability has been discovered that allows Node to be re-enabled in child windows.
|
||||
|
||||
---
|
||||
|
||||
Opening a BrowserView with `sandbox: true` or `nativeWindowOpen: true` and `nodeIntegration: false` results in a webContents where `window.open` can be called and the newly opened child window will have `nodeIntegration` enabled. This vulnerability affects all supported versions of Electron.
|
||||
|
||||
## Mitigation
|
||||
|
||||
We've published new versions of Electron which include fixes for this vulnerability:
|
||||
[`2.0.17`](https://github.com/electron/electron/releases/tag/v2.0.17),
|
||||
[`3.0.15`](https://github.com/electron/electron/releases/tag/v3.0.15),
|
||||
[`3.1.3`](https://github.com/electron/electron/releases/tag/v3.1.3),
|
||||
[`4.0.4`](https://github.com/electron/electron/releases/tag/v4.0.4), and
|
||||
[`5.0.0-beta.2`](https://github.com/electron/electron/releases/tag/v5.0.0-beta.2).
|
||||
We encourage all Electron developers to update their apps to the latest stable version immediately.
|
||||
|
||||
If for some reason you are unable to upgrade your Electron version, you can mitigate this issue by disabling all child web contents:
|
||||
|
||||
```javascript
|
||||
view.webContents.on('-add-new-contents', e => e.preventDefault());
|
||||
```
|
||||
|
||||
## Further Information
|
||||
|
||||
This vulnerability was found and reported responsibly to the Electron project by [PalmerAL](https://github.com/PalmerAL).
|
||||
|
||||
To learn more about best practices for keeping your Electron apps secure, see our [security tutorial].
|
||||
|
||||
If you wish to report a vulnerability in Electron, email security@electronjs.org.
|
||||
|
||||
[security tutorial]: https://electronjs.org/docs/tutorial/security
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
---
|
||||
title: 'Project of the Week: WordPress Desktop'
|
||||
author:
|
||||
- mkaz
|
||||
- johngodley
|
||||
- zeke
|
||||
date: '2017-02-28'
|
||||
---
|
||||
|
||||
This week we caught up with folks at [Automattic](https://automattic.com/) to
|
||||
talk about [WordPress Desktop](https://apps.wordpress.com/desktop/), an
|
||||
open-source desktop client for managing WordPress content.
|
||||
|
||||
---
|
||||
|
||||
[](https://apps.wordpress.com/desktop/)
|
||||
|
||||
## Everyone knows about WordPress, but what is WordPress Desktop?
|
||||
|
||||
The [WordPress.com Desktop app](https://apps.wordpress.com/desktop/) provides a seamless cross-platform experience that allows you to focus on your content and design with no browser tabs to distract you — or to keep your sites sidelined but accessible. In combination with our browser support and mobile app you can build your site anywhere, in whatever way helps you get your work done.
|
||||
|
||||
## Why build a Desktop app for managing WordPress sites? Couldn't it all be web-based?
|
||||
|
||||
It's actually using exactly the same technology you get when visiting [WordPress.com](https://wordpress.com) in your browser. However, it's all locally hosted, so it has minimal load times. With the benefit of native features such as being in your dock, notifications, etc., you really can focus on your WordPress sites and blogging.
|
||||
|
||||
## Why did you choose to build WordPress Desktop on Electron?
|
||||
|
||||
At the end of 2015 we rebuilt much of WordPress.com in the form of [Calypso](https://github.com/automattic/wp-calypso), an open-source modern JavaScript app using React. We started looking at Electron and with some changes to Calypso were able to get it running locally. It was a compelling experience and we thought there was a lot of value in developing it further.
|
||||
|
||||
We had several teams working on Calypso. To make a full multi-platform GUI client that matched this using traditional desktop technologies would have taken more work. By using Electron, a small team of 2-4 of us were able to leverage the other team’s efforts and build the Desktop app in a couple of months.
|
||||
|
||||
## What are some challenges you've faced while building WordPress Desktop?
|
||||
|
||||
We got an initial version of the app running very quickly, but tuning it to behave optimally as a desktop app took a lot more time. One big challenge with the app is that you're actually running a copy of Calypso on your own machine - it’s purely an API driven UI. There was a lot of bridging work involved in this, and changes were fed back to Calypso itself.
|
||||
|
||||
Additionally a lot of effort was spent packaging the app for different platforms - we provide Windows, macOS, and Linux versions - and there are sufficient differences to make this tricky.
|
||||
|
||||
At the time Electron was relatively new and we kept running into issues that were shortly fixed (sometimes the same day!)
|
||||
|
||||
## In what areas should Electron be improved?
|
||||
|
||||
Electron already provides most of what we need for the Desktop app, and it's progressed rapidly since we started using it. That said, there are some areas that are taken for granted in a desktop app, such as spell checking and find/replace, that are harder to replicate with Electron as-is.
|
||||
|
||||
We’d also love to see some of the newer Chrome technologies filtering down into Electron too. We’re particularly keen on experimenting with WebVR.
|
||||
|
||||
## What are your favorite things about Electron?
|
||||
|
||||
The main reason we chose Electron, and it's biggest strength, is the very active and open community. Automattic has always believed in open source. It is one of our core tenets, and the Electron project and community follows a lot of the core beliefs of being very open and positive.
|
||||
|
||||
## What's coming next in WordPress Desktop?
|
||||
|
||||
The great thing about our model is that the Desktop app benefits from any new Calypso feature - there are constant improvements. We’re hoping we can add additional features to the app such as offline support, which would really take the app into native territory, and better system notifications.
|
||||
|
||||
## Are there any teams at Automattic working on other Electron apps?
|
||||
|
||||
Yes, after our efforts on the Desktop app, the Simplenote team decided to use Electron to build desktop apps for Windows and Linux (a native Mac client already exists). The [Simplenote Electron app](https://github.com/Automattic/simplenote-electron) is also open source and available on Github.
|
||||
|
||||
We've also got an upcoming Raspberry Pi integration that uses Electron.
|
||||
|
||||
If any of that sounds interesting then we'd [love to hear from you](https://automattic.com/work-with-us/)!
|
||||
|
||||
## Any Electron tips that might be useful to other developers?
|
||||
|
||||
The process of shipping signed desktop software is relatively new to us, especially for Windows. we wrote up an article for [Code Signing a Windows App](https://mkaz.blog/code/code-signing-a-windows-application/) which includes the process and a few of the hurdles we went through to do it right.
|
||||
|
||||
164
docs/README.md
164
docs/README.md
|
|
@ -1,164 +0,0 @@
|
|||
---
|
||||
id: README
|
||||
---
|
||||
|
||||
# Official Guides
|
||||
|
||||
Please make sure that you use the documents that match your Electron version.
|
||||
The version number should be a part of the page URL. If it's not, you are
|
||||
probably using the documentation of a development branch which may contain API
|
||||
changes that are not compatible with your Electron version. To view older
|
||||
versions of the documentation, you can
|
||||
[browse by tag](https://github.com/electron/electron/tree/v1.4.0)
|
||||
on GitHub by opening the "Switch branches/tags" dropdown and selecting the tag
|
||||
that matches your version.
|
||||
|
||||
## FAQ
|
||||
|
||||
There are questions that are asked quite often. Check this out before creating
|
||||
an issue:
|
||||
|
||||
* [Electron FAQ](faq.md)
|
||||
|
||||
## Guides and Tutorials
|
||||
|
||||
### Quickstart
|
||||
|
||||
* [Quick Start Guide](tutorial/quick-start.md)
|
||||
* [Prerequisites](tutorial/quick-start.md#prerequisites)
|
||||
* [Create a basic application](tutorial/quick-start.md#create-a-basic-application)
|
||||
* [Run your application](tutorial/quick-start.md#run-your-application)
|
||||
* [Package and distribute the application](tutorial/quick-start.md#package-and-distribute-the-application)
|
||||
|
||||
### Learning the basics
|
||||
|
||||
* [Electron's Process Model](tutorial/quick-start.md#application-architecture)
|
||||
* [Main and Renderer Processes](tutorial/quick-start.md#main-and-renderer-processes)
|
||||
* [Electron API](tutorial/quick-start.md#electron-api)
|
||||
* [Node.js API](tutorial/quick-start.md#nodejs-api)
|
||||
* Adding Features to Your App
|
||||
* [Notifications](tutorial/notifications.md)
|
||||
* [Recent Documents](tutorial/recent-documents.md)
|
||||
* [Application Progress](tutorial/progress-bar.md)
|
||||
* [Custom Dock Menu](tutorial/macos-dock.md)
|
||||
* [Custom Windows Taskbar](tutorial/windows-taskbar.md)
|
||||
* [Custom Linux Desktop Actions](tutorial/linux-desktop-actions.md)
|
||||
* [Keyboard Shortcuts](tutorial/keyboard-shortcuts.md)
|
||||
* [Offline/Online Detection](tutorial/online-offline-events.md)
|
||||
* [Represented File for macOS BrowserWindows](tutorial/represented-file.md)
|
||||
* [Native File Drag & Drop](tutorial/native-file-drag-drop.md)
|
||||
* [Offscreen Rendering](tutorial/offscreen-rendering.md)
|
||||
* [Dark Mode](tutorial/dark-mode.md)
|
||||
* [Web embeds in Electron](tutorial/web-embeds.md)
|
||||
* [Boilerplates and CLIs](tutorial/boilerplates-and-clis.md)
|
||||
* [Boilerplate vs CLI](tutorial/boilerplates-and-clis.md#boilerplate-vs-cli)
|
||||
* [electron-forge](tutorial/boilerplates-and-clis.md#electron-forge)
|
||||
* [electron-builder](tutorial/boilerplates-and-clis.md#electron-builder)
|
||||
* [electron-react-boilerplate](tutorial/boilerplates-and-clis.md#electron-react-boilerplate)
|
||||
* [Other Tools and Boilerplates](tutorial/boilerplates-and-clis.md#other-tools-and-boilerplates)
|
||||
|
||||
### Advanced steps
|
||||
|
||||
* Application Architecture
|
||||
* [Using Native Node.js Modules](tutorial/using-native-node-modules.md)
|
||||
* [Performance Strategies](tutorial/performance.md)
|
||||
* [Security Strategies](tutorial/security.md)
|
||||
* [Accessibility](tutorial/accessibility.md)
|
||||
* [Manually Enabling Accessibility Features](tutorial/accessibility.md#manually-enabling-accessibility-features)
|
||||
* [Testing and Debugging](tutorial/application-debugging.md)
|
||||
* [Debugging the Main Process](tutorial/debugging-main-process.md)
|
||||
* [Debugging with Visual Studio Code](tutorial/debugging-vscode.md)
|
||||
* [Using Selenium and WebDriver](tutorial/using-selenium-and-webdriver.md)
|
||||
* [Testing on Headless CI Systems (Travis, Jenkins)](tutorial/testing-on-headless-ci.md)
|
||||
* [DevTools Extension](tutorial/devtools-extension.md)
|
||||
* [Automated Testing with a Custom Driver](tutorial/automated-testing-with-a-custom-driver.md)
|
||||
* [Distribution](tutorial/application-distribution.md)
|
||||
* [Supported Platforms](tutorial/support.md#supported-platforms)
|
||||
* [Code Signing](tutorial/code-signing.md)
|
||||
* [Mac App Store](tutorial/mac-app-store-submission-guide.md)
|
||||
* [Windows Store](tutorial/windows-store-guide.md)
|
||||
* [Snapcraft](tutorial/snapcraft.md)
|
||||
* [Updates](tutorial/updates.md)
|
||||
* [Deploying an Update Server](tutorial/updates.md#deploying-an-update-server)
|
||||
* [Implementing Updates in Your App](tutorial/updates.md#implementing-updates-in-your-app)
|
||||
* [Applying Updates](tutorial/updates.md#applying-updates)
|
||||
* [Getting Support](tutorial/support.md)
|
||||
|
||||
## Detailed Tutorials
|
||||
|
||||
These individual tutorials expand on topics discussed in the guide above.
|
||||
|
||||
* [Installing Electron](tutorial/installation.md)
|
||||
* [Proxies](tutorial/installation.md#proxies)
|
||||
* [Custom Mirrors and Caches](tutorial/installation.md#custom-mirrors-and-caches)
|
||||
* [Troubleshooting](tutorial/installation.md#troubleshooting)
|
||||
* Electron Releases & Developer Feedback
|
||||
* [Versioning Policy](tutorial/electron-versioning.md)
|
||||
* [Release Timelines](tutorial/electron-timelines.md)
|
||||
* [Testing Widevine CDM](tutorial/testing-widevine-cdm.md)
|
||||
|
||||
---
|
||||
|
||||
* [Glossary of Terms](glossary.md)
|
||||
|
||||
## API References
|
||||
|
||||
* [Synopsis](api/synopsis.md)
|
||||
* [Process Object](api/process.md)
|
||||
* [Supported Command Line Switches](api/command-line-switches.md)
|
||||
* [Environment Variables](api/environment-variables.md)
|
||||
* [Chrome Extensions Support](api/extensions.md)
|
||||
* [Breaking API Changes](breaking-changes.md)
|
||||
|
||||
### Custom DOM Elements:
|
||||
|
||||
* [`File` Object](api/file-object.md)
|
||||
* [`<webview>` Tag](api/webview-tag.md)
|
||||
* [`window.open` Function](api/window-open.md)
|
||||
* [`BrowserWindowProxy` Object](api/browser-window-proxy.md)
|
||||
|
||||
### Modules for the Main Process:
|
||||
|
||||
* [app](api/app.md)
|
||||
* [autoUpdater](api/auto-updater.md)
|
||||
* [BrowserView](api/browser-view.md)
|
||||
* [BrowserWindow](api/browser-window.md)
|
||||
* [contentTracing](api/content-tracing.md)
|
||||
* [dialog](api/dialog.md)
|
||||
* [globalShortcut](api/global-shortcut.md)
|
||||
* [inAppPurchase](api/in-app-purchase.md)
|
||||
* [ipcMain](api/ipc-main.md)
|
||||
* [Menu](api/menu.md)
|
||||
* [MenuItem](api/menu-item.md)
|
||||
* [net](api/net.md)
|
||||
* [netLog](api/net-log.md)
|
||||
* [nativeTheme](api/native-theme.md)
|
||||
* [Notification](api/notification.md)
|
||||
* [powerMonitor](api/power-monitor.md)
|
||||
* [powerSaveBlocker](api/power-save-blocker.md)
|
||||
* [protocol](api/protocol.md)
|
||||
* [screen](api/screen.md)
|
||||
* [session](api/session.md)
|
||||
* [systemPreferences](api/system-preferences.md)
|
||||
* [TouchBar](api/touch-bar.md)
|
||||
* [Tray](api/tray.md)
|
||||
* [webContents](api/web-contents.md)
|
||||
* [webFrameMain](api/web-frame-main.md)
|
||||
|
||||
### Modules for the Renderer Process (Web Page):
|
||||
|
||||
* [contextBridge](api/context-bridge.md)
|
||||
* [desktopCapturer](api/desktop-capturer.md)
|
||||
* [ipcRenderer](api/ipc-renderer.md)
|
||||
* [webFrame](api/web-frame.md)
|
||||
|
||||
### Modules for Both Processes:
|
||||
|
||||
* [clipboard](api/clipboard.md)
|
||||
* [crashReporter](api/crash-reporter.md)
|
||||
* [nativeImage](api/native-image.md)
|
||||
* [shell](api/shell.md)
|
||||
|
||||
## Development
|
||||
|
||||
See [development/README.md](development/README.md)
|
||||
|
|
@ -1,84 +0,0 @@
|
|||
---
|
||||
id: accelerator
|
||||
title: accelerator
|
||||
---
|
||||
|
||||
> Define keyboard shortcuts.
|
||||
|
||||
Accelerators are Strings that can contain multiple modifiers and a single key code,
|
||||
combined by the `+` character, and are used to define keyboard shortcuts
|
||||
throughout your application.
|
||||
|
||||
Examples:
|
||||
|
||||
* `CommandOrControl+A`
|
||||
* `CommandOrControl+Shift+Z`
|
||||
|
||||
Shortcuts are registered with the [`globalShortcut`](global-shortcut.md) module
|
||||
using the [`register`](global-shortcut.md#globalshortcutregisteraccelerator-callback)
|
||||
method, i.e.
|
||||
|
||||
```javascript
|
||||
const { app, globalShortcut } = require('electron')
|
||||
|
||||
app.whenReady().then(() => {
|
||||
// Register a 'CommandOrControl+Y' shortcut listener.
|
||||
globalShortcut.register('CommandOrControl+Y', () => {
|
||||
// Do stuff when Y and either Command/Control is pressed.
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Platform notice
|
||||
|
||||
On Linux and Windows, the `Command` key does not have any effect so
|
||||
use `CommandOrControl` which represents `Command` on macOS and `Control` on
|
||||
Linux and Windows to define some accelerators.
|
||||
|
||||
Use `Alt` instead of `Option`. The `Option` key only exists on macOS, whereas
|
||||
the `Alt` key is available on all platforms.
|
||||
|
||||
The `Super` key is mapped to the `Windows` key on Windows and Linux and
|
||||
`Cmd` on macOS.
|
||||
|
||||
## Available modifiers
|
||||
|
||||
* `Command` (or `Cmd` for short)
|
||||
* `Control` (or `Ctrl` for short)
|
||||
* `CommandOrControl` (or `CmdOrCtrl` for short)
|
||||
* `Alt`
|
||||
* `Option`
|
||||
* `AltGr`
|
||||
* `Shift`
|
||||
* `Super`
|
||||
|
||||
## Available key codes
|
||||
|
||||
* `0` to `9`
|
||||
* `A` to `Z`
|
||||
* `F1` to `F24`
|
||||
* Punctuation like `~`, `!`, `@`, `#`, `$`, etc.
|
||||
* `Plus`
|
||||
* `Space`
|
||||
* `Tab`
|
||||
* `Capslock`
|
||||
* `Numlock`
|
||||
* `Scrolllock`
|
||||
* `Backspace`
|
||||
* `Delete`
|
||||
* `Insert`
|
||||
* `Return` (or `Enter` as alias)
|
||||
* `Up`, `Down`, `Left` and `Right`
|
||||
* `Home` and `End`
|
||||
* `PageUp` and `PageDown`
|
||||
* `Escape` (or `Esc` for short)
|
||||
* `VolumeUp`, `VolumeDown` and `VolumeMute`
|
||||
* `MediaNextTrack`, `MediaPreviousTrack`, `MediaStop` and `MediaPlayPause`
|
||||
* `PrintScreen`
|
||||
* NumPad Keys
|
||||
* `num0` - `num9`
|
||||
* `numdec` - decimal key
|
||||
* `numadd` - numpad `+` key
|
||||
* `numsub` - numpad `-` key
|
||||
* `nummult` - numpad `*` key
|
||||
* `numdiv` - numpad `÷` key
|
||||
1448
docs/api/app.md
1448
docs/api/app.md
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
|
|
@ -1,144 +0,0 @@
|
|||
# autoUpdater
|
||||
|
||||
> Enable apps to automatically update themselves.
|
||||
|
||||
Process: [Main](../glossary.md#main-process)
|
||||
|
||||
**See also: [A detailed guide about how to implement updates in your application](../tutorial/updates.md).**
|
||||
|
||||
`autoUpdater` is an [EventEmitter][event-emitter].
|
||||
|
||||
## Platform Notices
|
||||
|
||||
Currently, only macOS and Windows are supported. There is no built-in support
|
||||
for auto-updater on Linux, so it is recommended to use the
|
||||
distribution's package manager to update your app.
|
||||
|
||||
In addition, there are some subtle differences on each platform:
|
||||
|
||||
### macOS
|
||||
|
||||
On macOS, the `autoUpdater` module is built upon [Squirrel.Mac][squirrel-mac],
|
||||
meaning you don't need any special setup to make it work. For server-side
|
||||
requirements, you can read [Server Support][server-support]. Note that [App
|
||||
Transport Security](https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW35) (ATS) applies to all requests made as part of the
|
||||
update process. Apps that need to disable ATS can add the
|
||||
`NSAllowsArbitraryLoads` key to their app's plist.
|
||||
|
||||
**Note:** Your application must be signed for automatic updates on macOS.
|
||||
This is a requirement of `Squirrel.Mac`.
|
||||
|
||||
### Windows
|
||||
|
||||
On Windows, you have to install your app into a user's machine before you can
|
||||
use the `autoUpdater`, so it is recommended that you use the
|
||||
[electron-winstaller][installer-lib], [electron-forge][electron-forge-lib] or the [grunt-electron-installer][installer] package to generate a Windows installer.
|
||||
|
||||
When using [electron-winstaller][installer-lib] or [electron-forge][electron-forge-lib] make sure you do not try to update your app [the first time it runs](https://github.com/electron/windows-installer#handling-squirrel-events) (Also see [this issue for more info](https://github.com/electron/electron/issues/7155)). It's also recommended to use [electron-squirrel-startup](https://github.com/mongodb-js/electron-squirrel-startup) to get desktop shortcuts for your app.
|
||||
|
||||
The installer generated with Squirrel will create a shortcut icon with an
|
||||
[Application User Model ID][app-user-model-id] in the format of
|
||||
`com.squirrel.PACKAGE_ID.YOUR_EXE_WITHOUT_DOT_EXE`, examples are
|
||||
`com.squirrel.slack.Slack` and `com.squirrel.code.Code`. You have to use the
|
||||
same ID for your app with `app.setAppUserModelId` API, otherwise Windows will
|
||||
not be able to pin your app properly in task bar.
|
||||
|
||||
Unlike Squirrel.Mac, Windows can host updates on S3 or any other static file host.
|
||||
You can read the documents of [Squirrel.Windows][squirrel-windows] to get more details
|
||||
about how Squirrel.Windows works.
|
||||
|
||||
## Events
|
||||
|
||||
The `autoUpdater` object emits the following events:
|
||||
|
||||
### Event: 'error'
|
||||
|
||||
Returns:
|
||||
|
||||
* `error` Error
|
||||
|
||||
Emitted when there is an error while updating.
|
||||
|
||||
### Event: 'checking-for-update'
|
||||
|
||||
Emitted when checking if an update has started.
|
||||
|
||||
### Event: 'update-available'
|
||||
|
||||
Emitted when there is an available update. The update is downloaded
|
||||
automatically.
|
||||
|
||||
### Event: 'update-not-available'
|
||||
|
||||
Emitted when there is no available update.
|
||||
|
||||
### Event: 'update-downloaded'
|
||||
|
||||
Returns:
|
||||
|
||||
* `event` Event
|
||||
* `releaseNotes` String
|
||||
* `releaseName` String
|
||||
* `releaseDate` Date
|
||||
* `updateURL` String
|
||||
|
||||
Emitted when an update has been downloaded.
|
||||
|
||||
On Windows only `releaseName` is available.
|
||||
|
||||
**Note:** It is not strictly necessary to handle this event. A successfully
|
||||
downloaded update will still be applied the next time the application starts.
|
||||
|
||||
### Event: 'before-quit-for-update'
|
||||
|
||||
This event is emitted after a user calls `quitAndInstall()`.
|
||||
|
||||
When this API is called, the `before-quit` event is not emitted before all windows are closed. As a result you should listen to this event if you wish to perform actions before the windows are closed while a process is quitting, as well as listening to `before-quit`.
|
||||
|
||||
## Methods
|
||||
|
||||
The `autoUpdater` object has the following methods:
|
||||
|
||||
### `autoUpdater.setFeedURL(options)`
|
||||
|
||||
* `options` Object
|
||||
* `url` String
|
||||
* `headers` Record<String, String> (optional) _macOS_ - HTTP request headers.
|
||||
* `serverType` String (optional) _macOS_ - Can be `json` or `default`, see the [Squirrel.Mac][squirrel-mac]
|
||||
README for more information.
|
||||
|
||||
Sets the `url` and initialize the auto updater.
|
||||
|
||||
### `autoUpdater.getFeedURL()`
|
||||
|
||||
Returns `String` - The current update feed URL.
|
||||
|
||||
### `autoUpdater.checkForUpdates()`
|
||||
|
||||
Asks the server whether there is an update. You must call `setFeedURL` before
|
||||
using this API.
|
||||
|
||||
**Note:** If an update is available it will be downloaded automatically.
|
||||
Calling `autoUpdater.checkForUpdates()` twice will download the update two times.
|
||||
|
||||
### `autoUpdater.quitAndInstall()`
|
||||
|
||||
Restarts the app and installs the update after it has been downloaded. It
|
||||
should only be called after `update-downloaded` has been emitted.
|
||||
|
||||
Under the hood calling `autoUpdater.quitAndInstall()` will close all application
|
||||
windows first, and automatically call `app.quit()` after all windows have been
|
||||
closed.
|
||||
|
||||
**Note:** It is not strictly necessary to call this function to apply an update,
|
||||
as a successfully downloaded update will always be applied the next time the
|
||||
application starts.
|
||||
|
||||
[squirrel-mac]: https://github.com/Squirrel/Squirrel.Mac
|
||||
[server-support]: https://github.com/Squirrel/Squirrel.Mac#server-support
|
||||
[squirrel-windows]: https://github.com/Squirrel/Squirrel.Windows
|
||||
[installer]: https://github.com/electron/grunt-electron-installer
|
||||
[installer-lib]: https://github.com/electron/windows-installer
|
||||
[electron-forge-lib]: https://github.com/electron-userland/electron-forge
|
||||
[app-user-model-id]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd378459(v=vs.85).aspx
|
||||
[event-emitter]: https://nodejs.org/api/events.html#events_class_eventemitter
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
# Experimental APIs
|
||||
|
||||
Some of Electrons APIs are tagged with `_Experimental_` in the documentation.
|
||||
This tag indicates that the API may not be considered stable and the API may
|
||||
be removed or modified more frequently than other APIs with less warning.
|
||||
|
||||
## Conditions for an API to be tagged as Experimental
|
||||
|
||||
Anyone can request an API be tagged as experimental in a feature PR, disagreements
|
||||
on the experimental nature of a feature can be discussed in the API WG if they
|
||||
can't be resolved in the PR.
|
||||
|
||||
## Process for removing the Experimental tag
|
||||
|
||||
Once an API has been stable and in at least two major stable release lines it
|
||||
can be nominated to have its experimental tag removed. This discussion should
|
||||
happen at an API WG meeting. Things to consider when discussing / nominating:
|
||||
|
||||
* The above "two major stables release lines" condition must have been met
|
||||
* During that time no major bugs / issues should have been caused by the adoption of this feature
|
||||
* The API is stable enough and hasn't been heavily impacted by Chromium upgrades
|
||||
* Is anyone using the API?
|
||||
* Is the API fulfilling the original proposed usecases, does it have any gaps?
|
||||
164
docs/faq.md
164
docs/faq.md
|
|
@ -1,164 +0,0 @@
|
|||
# Electron FAQ
|
||||
|
||||
## Why am I having trouble installing Electron?
|
||||
|
||||
When running `npm install electron`, some users occasionally encounter
|
||||
installation errors.
|
||||
|
||||
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
|
||||
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)
|
||||
if installing via `npm` is failing.
|
||||
|
||||
## When will Electron upgrade to latest Chrome?
|
||||
|
||||
The Chrome version of Electron is usually bumped within one or two weeks after
|
||||
a new stable Chrome version gets released. This estimate is not guaranteed and
|
||||
depends on the amount of work involved with upgrading.
|
||||
|
||||
Only the stable channel of Chrome is used. If an important fix is in beta or dev
|
||||
channel, we will back-port it.
|
||||
|
||||
For more information, please see the [security introduction](tutorial/security.md).
|
||||
|
||||
## When will Electron upgrade to latest Node.js?
|
||||
|
||||
When a new version of Node.js gets released, we usually wait for about a month
|
||||
before upgrading the one in Electron. So we can avoid getting affected by bugs
|
||||
introduced in new Node.js versions, which happens very often.
|
||||
|
||||
New features of Node.js are usually brought by V8 upgrades, since Electron is
|
||||
using the V8 shipped by Chrome browser, the shiny new JavaScript feature of a
|
||||
new Node.js version is usually already in Electron.
|
||||
|
||||
## How to share data between web pages?
|
||||
|
||||
To share data between web pages (the renderer processes) the simplest way is to
|
||||
use HTML5 APIs which are already available in browsers. Good candidates are
|
||||
[Storage API][storage], [`localStorage`][local-storage],
|
||||
[`sessionStorage`][session-storage], and [IndexedDB][indexed-db].
|
||||
|
||||
Alternatively, you can use the IPC primitives that are provided by Electron. To
|
||||
share data between the main and renderer processes, you can use the
|
||||
[`ipcMain`](api/ipc-main.md) and [`ipcRenderer`](api/ipc-renderer.md) modules.
|
||||
To communicate directly between web pages, you can send a
|
||||
[`MessagePort`][message-port] from one to the other, possibly via the main process
|
||||
using [`ipcRenderer.postMessage()`](api/ipc-renderer.md#ipcrendererpostmessagechannel-message-transfer).
|
||||
Subsequent communication over message ports is direct and does not detour through
|
||||
the main process.
|
||||
|
||||
## My app's tray disappeared after a few minutes.
|
||||
|
||||
This happens when the variable which is used to store the tray gets
|
||||
garbage collected.
|
||||
|
||||
If you encounter this problem, the following articles may prove helpful:
|
||||
|
||||
* [Memory Management][memory-management]
|
||||
* [Variable Scope][variable-scope]
|
||||
|
||||
If you want a quick fix, you can make the variables global by changing your
|
||||
code from this:
|
||||
|
||||
```javascript
|
||||
const { app, Tray } = require('electron')
|
||||
app.whenReady().then(() => {
|
||||
const tray = new Tray('/path/to/icon.png')
|
||||
tray.setTitle('hello world')
|
||||
})
|
||||
```
|
||||
|
||||
to this:
|
||||
|
||||
```javascript
|
||||
const { app, Tray } = require('electron')
|
||||
let tray = null
|
||||
app.whenReady().then(() => {
|
||||
tray = new Tray('/path/to/icon.png')
|
||||
tray.setTitle('hello world')
|
||||
})
|
||||
```
|
||||
|
||||
## I can not use jQuery/RequireJS/Meteor/AngularJS in Electron.
|
||||
|
||||
Due to the Node.js integration of Electron, there are some extra symbols
|
||||
inserted into the DOM like `module`, `exports`, `require`. This causes problems
|
||||
for some libraries since they want to insert the symbols with the same names.
|
||||
|
||||
To solve this, you can turn off node integration in Electron:
|
||||
|
||||
```javascript
|
||||
// In the main process.
|
||||
const { BrowserWindow } = require('electron')
|
||||
const win = new BrowserWindow({
|
||||
webPreferences: {
|
||||
nodeIntegration: false
|
||||
}
|
||||
})
|
||||
win.show()
|
||||
```
|
||||
|
||||
But if you want to keep the abilities of using Node.js and Electron APIs, you
|
||||
have to rename the symbols in the page before including other libraries:
|
||||
|
||||
```html
|
||||
<head>
|
||||
<script>
|
||||
window.nodeRequire = require;
|
||||
delete window.require;
|
||||
delete window.exports;
|
||||
delete window.module;
|
||||
</script>
|
||||
<script type="text/javascript" src="jquery.js"></script>
|
||||
</head>
|
||||
```
|
||||
|
||||
## `require('electron').xxx` is undefined.
|
||||
|
||||
When using Electron's built-in module you might encounter an error like this:
|
||||
|
||||
```sh
|
||||
> require('electron').webFrame.setZoomFactor(1.0)
|
||||
Uncaught TypeError: Cannot read property 'setZoomLevel' of undefined
|
||||
```
|
||||
|
||||
It is very likely you are using the module in the wrong process. For example
|
||||
`electron.app` can only be used in the main process, while `electron.webFrame`
|
||||
is only available in renderer processes.
|
||||
|
||||
## The font looks blurry, what is this and what can I do?
|
||||
|
||||
If [sub-pixel anti-aliasing](https://alienryderflex.com/sub_pixel/) is deactivated, then fonts on LCD screens can look blurry. Example:
|
||||
|
||||
![subpixel rendering example]
|
||||
|
||||
Sub-pixel anti-aliasing needs a non-transparent background of the layer containing the font glyphs. (See [this issue](https://github.com/electron/electron/issues/6344#issuecomment-420371918) for more info).
|
||||
|
||||
To achieve this goal, set the background in the constructor for [BrowserWindow][browser-window]:
|
||||
|
||||
```javascript
|
||||
const { BrowserWindow } = require('electron')
|
||||
const win = new BrowserWindow({
|
||||
backgroundColor: '#fff'
|
||||
})
|
||||
```
|
||||
|
||||
The effect is visible only on (some?) LCD screens. Even if you don't see a difference, some of your users may. It is best to always set the background this way, unless you have reasons not to do so.
|
||||
|
||||
Notice that just setting the background in the CSS does not have the desired effect.
|
||||
|
||||
[memory-management]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management
|
||||
[variable-scope]: https://msdn.microsoft.com/library/bzt2dkta(v=vs.94).aspx
|
||||
[electron-module]: https://www.npmjs.com/package/electron
|
||||
[storage]: https://developer.mozilla.org/en-US/docs/Web/API/Storage
|
||||
[local-storage]: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
|
||||
[session-storage]: https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage
|
||||
[indexed-db]: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
|
||||
[message-port]: https://developer.mozilla.org/en-US/docs/Web/API/MessagePort
|
||||
[browser-window]: api/browser-window.md
|
||||
[subpixel rendering example]: images/subpixel-rendering-screenshot.gif
|
||||
186
docs/glossary.md
186
docs/glossary.md
|
|
@ -1,186 +0,0 @@
|
|||
# Glossary
|
||||
|
||||
This page defines some terminology that is commonly used in Electron development.
|
||||
|
||||
### ASAR
|
||||
|
||||
ASAR stands for Atom Shell Archive Format. An [asar][asar] archive is a simple
|
||||
`tar`-like format that concatenates files into a single file. Electron can read
|
||||
arbitrary files from it without unpacking the whole file.
|
||||
|
||||
The ASAR format was created primarily to improve performance on Windows... TODO
|
||||
|
||||
### CRT
|
||||
|
||||
The C Run-time Library (CRT) is the part of the C++ Standard Library that
|
||||
incorporates the ISO C99 standard library. The Visual C++ libraries that
|
||||
implement the CRT support native code development, and both mixed native and
|
||||
managed code, and pure managed code for .NET development.
|
||||
|
||||
### DMG
|
||||
|
||||
An Apple Disk Image is a packaging format used by macOS. DMG files are
|
||||
commonly used for distributing application "installers". [electron-builder]
|
||||
supports `dmg` as a build target.
|
||||
|
||||
### IME
|
||||
|
||||
Input Method Editor. A program that allows users to enter characters and
|
||||
symbols not found on their keyboard. For example, this allows users of Latin
|
||||
keyboards to input Chinese, Japanese, Korean and Indic characters.
|
||||
|
||||
### IDL
|
||||
|
||||
Interface description language. Write function signatures and data types in a format that can be used to generate interfaces in Java, C++, JavaScript, etc.
|
||||
|
||||
### IPC
|
||||
|
||||
IPC stands for Inter-Process Communication. Electron uses IPC to send
|
||||
serialized JSON messages between the [main] and [renderer] processes.
|
||||
|
||||
### libchromiumcontent
|
||||
|
||||
A shared library that includes the [Chromium Content module] and all its
|
||||
dependencies (e.g., Blink, [V8], etc.). Also referred to as "libcc".
|
||||
|
||||
- [github.com/electron/libchromiumcontent](https://github.com/electron/libchromiumcontent)
|
||||
|
||||
### main process
|
||||
|
||||
The main process, commonly a file named `main.js`, is the entry point to every
|
||||
Electron app. It controls the life of the app, from open to close. It also
|
||||
manages native elements such as the Menu, Menu Bar, Dock, Tray, etc. The
|
||||
main process is responsible for creating each new renderer process in the app.
|
||||
The full Node API is built in.
|
||||
|
||||
Every app's main process file is specified in the `main` property in
|
||||
`package.json`. This is how `electron .` knows what file to execute at startup.
|
||||
|
||||
In Chromium, this process is referred to as the "browser process". It is
|
||||
renamed in Electron to avoid confusion with renderer processes.
|
||||
|
||||
See also: [process](#process), [renderer process](#renderer-process)
|
||||
|
||||
### MAS
|
||||
|
||||
Acronym for Apple's Mac App Store. For details on submitting your app to the
|
||||
MAS, see the [Mac App Store Submission Guide].
|
||||
|
||||
### Mojo
|
||||
|
||||
An IPC system for communicating intra- or inter-process, and that's important because Chrome is keen on being able to split its work into separate processes or not, depending on memory pressures etc.
|
||||
|
||||
See https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md
|
||||
|
||||
### native modules
|
||||
|
||||
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 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.
|
||||
|
||||
Native Node modules are supported by Electron, but since Electron is very
|
||||
likely to use a different V8 version from the Node binary installed in your
|
||||
system, you have to manually specify the location of Electron’s headers when
|
||||
building native modules.
|
||||
|
||||
See also [Using Native Node Modules].
|
||||
|
||||
### NSIS
|
||||
|
||||
Nullsoft Scriptable Install System is a script-driven Installer
|
||||
authoring tool for Microsoft Windows. It is released under a combination of
|
||||
free software licenses, and is a widely-used alternative to commercial
|
||||
proprietary products like InstallShield. [electron-builder] supports NSIS
|
||||
as a build target.
|
||||
|
||||
### OSR
|
||||
|
||||
OSR (Off-screen rendering) can be used for loading heavy page in
|
||||
background and then displaying it after (it will be much faster).
|
||||
It allows you to render page without showing it on screen.
|
||||
|
||||
### process
|
||||
|
||||
A process is an instance of a computer program that is being executed. Electron
|
||||
apps that make use of the [main] and one or many [renderer] process are
|
||||
actually running several programs simultaneously.
|
||||
|
||||
In Node.js and Electron, each running process has a `process` object. This
|
||||
object is a global that provides information about, and control over, the
|
||||
current process. As a global, it is always available to applications without
|
||||
using require().
|
||||
|
||||
See also: [main process](#main-process), [renderer process](#renderer-process)
|
||||
|
||||
### renderer process
|
||||
|
||||
The renderer process is a browser window in your app. Unlike the main process,
|
||||
there can be multiple of these and each is run in a separate process.
|
||||
They can also be hidden.
|
||||
|
||||
In normal browsers, web pages usually run in a sandboxed environment and are not
|
||||
allowed access to native resources. Electron users, however, have the power to
|
||||
use Node.js APIs in web pages allowing lower level operating system
|
||||
interactions.
|
||||
|
||||
See also: [process](#process), [main process](#main-process)
|
||||
|
||||
### Squirrel
|
||||
|
||||
Squirrel is an open-source framework that enables Electron apps to update
|
||||
automatically as new versions are released. See the [autoUpdater] API for
|
||||
info about getting started with Squirrel.
|
||||
|
||||
### userland
|
||||
|
||||
This term originated in the Unix community, where "userland" or "userspace"
|
||||
referred to programs that run outside of the operating system kernel. More
|
||||
recently, the term has been popularized in the Node and npm community to
|
||||
distinguish between the features available in "Node core" versus packages
|
||||
published to the npm registry by the much larger "user" community.
|
||||
|
||||
Like Node, Electron is focused on having a small set of APIs that provide
|
||||
all the necessary primitives for developing multi-platform desktop applications.
|
||||
This design philosophy allows Electron to remain a flexible tool without being
|
||||
overly prescriptive about how it should be used. Userland enables users to
|
||||
create and share tools that provide additional functionality on top of what is
|
||||
available in "core".
|
||||
|
||||
### V8
|
||||
|
||||
V8 is Google's open source JavaScript engine. It is written in C++ and is
|
||||
used in Google Chrome. V8 can run standalone, or can be embedded into any C++ application.
|
||||
|
||||
Electron builds V8 as part of Chromium and then points Node to that V8 when
|
||||
building it.
|
||||
|
||||
V8's version numbers always correspond to those of Google Chrome. Chrome 59
|
||||
includes V8 5.9, Chrome 58 includes V8 5.8, etc.
|
||||
|
||||
- [v8.dev](https://v8.dev/)
|
||||
- [nodejs.org/api/v8.html](https://nodejs.org/api/v8.html)
|
||||
- [docs/development/v8-development.md](development/v8-development.md)
|
||||
|
||||
### webview
|
||||
|
||||
`webview` tags are used to embed 'guest' content (such as external web pages) in
|
||||
your Electron app. They are similar to `iframe`s, but differ in that each
|
||||
webview runs in a separate process. It doesn't have the same
|
||||
permissions as your web page and all interactions between your app and
|
||||
embedded content will be asynchronous. This keeps your app safe from the
|
||||
embedded content.
|
||||
|
||||
[addons]: https://nodejs.org/api/addons.html
|
||||
[asar]: https://github.com/electron/asar
|
||||
[autoUpdater]: api/auto-updater.md
|
||||
[Chromium Content module]: https://www.chromium.org/developers/content-module
|
||||
[electron-builder]: https://github.com/electron-userland/electron-builder
|
||||
[libchromiumcontent]: #libchromiumcontent
|
||||
[Mac App Store Submission Guide]: tutorial/mac-app-store-submission-guide.md
|
||||
[main]: #main-process
|
||||
[renderer]: #renderer-process
|
||||
[userland]: #userland
|
||||
[Using Native Node Modules]: tutorial/using-native-node-modules.md
|
||||
[V8]: #v8
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
id: introduction
|
||||
title: Introduction
|
||||
---
|
||||
|
|
@ -1,234 +0,0 @@
|
|||
# Electron Documentation Style Guide
|
||||
|
||||
These are the guidelines for writing Electron documentation.
|
||||
|
||||
## Titles
|
||||
|
||||
* Each page must have a single `#`-level title at the top.
|
||||
* Chapters in the same page must have `##`-level titles.
|
||||
* Sub-chapters need to increase the number of `#` in the title according to
|
||||
their nesting depth.
|
||||
* All words in the page's title must be capitalized, except for conjunctions
|
||||
like "of" and "and" .
|
||||
* Only the first word of a chapter title must be capitalized.
|
||||
|
||||
Using `Quick Start` as example:
|
||||
|
||||
```markdown
|
||||
# Quick Start
|
||||
|
||||
...
|
||||
|
||||
## Main process
|
||||
|
||||
...
|
||||
|
||||
## Renderer process
|
||||
|
||||
...
|
||||
|
||||
## Run your app
|
||||
|
||||
...
|
||||
|
||||
### Run as a distribution
|
||||
|
||||
...
|
||||
|
||||
### Manually downloaded Electron binary
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
For API references, there are exceptions to this rule.
|
||||
|
||||
## Markdown rules
|
||||
|
||||
* Use `sh` instead of `cmd` in code blocks (due to the syntax highlighter).
|
||||
* Lines should be wrapped at 80 columns.
|
||||
* No nesting lists more than 2 levels (due to the markdown renderer).
|
||||
* All `js` and `javascript` code blocks are linted with
|
||||
[standard-markdown](https://www.npmjs.com/package/standard-markdown).
|
||||
* For unordered lists, use asterisks instead of dashes
|
||||
|
||||
## Picking words
|
||||
|
||||
* Use "will" over "would" when describing outcomes.
|
||||
* Prefer "in the ___ process" over "on".
|
||||
|
||||
## API references
|
||||
|
||||
The following rules only apply to the documentation of APIs.
|
||||
|
||||
### Page title
|
||||
|
||||
Each page must use the actual object name returned by `require('electron')`
|
||||
as the title, such as `BrowserWindow`, `autoUpdater`, and `session`.
|
||||
|
||||
Under the page title must be a one-line description starting with `>`.
|
||||
|
||||
Using `session` as example:
|
||||
|
||||
```markdown
|
||||
# session
|
||||
|
||||
> Manage browser sessions, cookies, cache, proxy settings, etc.
|
||||
```
|
||||
|
||||
### Module methods and events
|
||||
|
||||
For modules that are not classes, their methods and events must be listed under
|
||||
the `## Methods` and `## Events` chapters.
|
||||
|
||||
Using `autoUpdater` as an example:
|
||||
|
||||
```markdown
|
||||
# autoUpdater
|
||||
|
||||
## Events
|
||||
|
||||
### Event: 'error'
|
||||
|
||||
## Methods
|
||||
|
||||
### `autoUpdater.setFeedURL(url[, requestHeaders])`
|
||||
```
|
||||
|
||||
### Classes
|
||||
|
||||
* API classes or classes that are part of modules must be listed under a
|
||||
`## Class: TheClassName` chapter.
|
||||
* One page can have multiple classes.
|
||||
* Constructors must be listed with `###`-level titles.
|
||||
* [Static Methods](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static) must be listed under a `### Static Methods` chapter.
|
||||
* [Instance Methods](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#Prototype_methods) must be listed under an `### Instance Methods` chapter.
|
||||
* All methods that have a return value must start their description with "Returns `[TYPE]` - Return description"
|
||||
* If the method returns an `Object`, its structure can be specified using a colon followed by a newline then an unordered list of properties in the same style as function parameters.
|
||||
* Instance Events must be listed under an `### Instance Events` chapter.
|
||||
* Instance Properties must be listed under an `### Instance Properties` chapter.
|
||||
* Instance properties must start with "A [Property Type] ..."
|
||||
|
||||
Using the `Session` and `Cookies` classes as an example:
|
||||
|
||||
```markdown
|
||||
# session
|
||||
|
||||
## Methods
|
||||
|
||||
### session.fromPartition(partition)
|
||||
|
||||
## Static Properties
|
||||
|
||||
### session.defaultSession
|
||||
|
||||
## Class: Session
|
||||
|
||||
### Instance Events
|
||||
|
||||
#### Event: 'will-download'
|
||||
|
||||
### Instance Methods
|
||||
|
||||
#### `ses.getCacheSize()`
|
||||
|
||||
### Instance Properties
|
||||
|
||||
#### `ses.cookies`
|
||||
|
||||
## Class: Cookies
|
||||
|
||||
### Instance Methods
|
||||
|
||||
#### `cookies.get(filter, callback)`
|
||||
```
|
||||
|
||||
### Methods
|
||||
|
||||
The methods chapter must be in the following form:
|
||||
|
||||
```markdown
|
||||
### `objectName.methodName(required[, optional]))`
|
||||
|
||||
* `required` String - A parameter description.
|
||||
* `optional` Integer (optional) - Another parameter description.
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
The title can be `###` or `####`-levels depending on whether it is a method of
|
||||
a module or a class.
|
||||
|
||||
For modules, the `objectName` is the module's name. For classes, it must be the
|
||||
name of the instance of the class, and must not be the same as the module's
|
||||
name.
|
||||
|
||||
For example, the methods of the `Session` class under the `session` module must
|
||||
use `ses` as the `objectName`.
|
||||
|
||||
The optional arguments are notated by square brackets `[]` surrounding the optional argument
|
||||
as well as the comma required if this optional argument follows another
|
||||
argument:
|
||||
|
||||
```sh
|
||||
required[, optional]
|
||||
```
|
||||
|
||||
Below the method is more detailed information on each of the arguments. The type
|
||||
of argument is notated by either the common types:
|
||||
|
||||
* [`String`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)
|
||||
* [`Number`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)
|
||||
* [`Object`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)
|
||||
* [`Array`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)
|
||||
* [`Boolean`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)
|
||||
* Or a custom type like Electron's [`WebContent`](api/web-contents.md)
|
||||
|
||||
If an argument or a method is unique to certain platforms, those platforms are
|
||||
denoted using a space-delimited italicized list following the datatype. Values
|
||||
can be `macOS`, `Windows` or `Linux`.
|
||||
|
||||
```markdown
|
||||
* `animate` Boolean (optional) _macOS_ _Windows_ - Animate the thing.
|
||||
```
|
||||
|
||||
`Array` type arguments must specify what elements the array may include in
|
||||
the description below.
|
||||
|
||||
The description for `Function` type arguments should make it clear how it may be
|
||||
called and list the types of the parameters that will be passed to it.
|
||||
|
||||
### Events
|
||||
|
||||
The events chapter must be in following form:
|
||||
|
||||
```markdown
|
||||
### Event: 'wake-up'
|
||||
|
||||
Returns:
|
||||
|
||||
* `time` String
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
The title can be `###` or `####`-levels depending on whether it is an event of
|
||||
a module or a class.
|
||||
|
||||
The arguments of an event follow the same rules as methods.
|
||||
|
||||
### Properties
|
||||
|
||||
The properties chapter must be in following form:
|
||||
|
||||
```markdown
|
||||
### session.defaultSession
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
The title can be `###` or `####`-levels depending on whether it is a property of
|
||||
a module or a class.
|
||||
|
||||
## Documentation Translations
|
||||
|
||||
See [electron/i18n](https://github.com/electron/i18n#readme)
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
id: what-is-electron
|
||||
title: What is Electron?
|
||||
---
|
||||
|
|
@ -20,7 +20,7 @@ module.exports = {
|
|||
{
|
||||
label: 'Docs',
|
||||
type: 'doc',
|
||||
docId: 'introduction',
|
||||
docId: 'get-started/quick-start',
|
||||
position: 'left',
|
||||
},
|
||||
{
|
||||
|
|
@ -29,7 +29,7 @@ module.exports = {
|
|||
docId: 'api/accelerator',
|
||||
position: 'left',
|
||||
},
|
||||
{to: 'blog', label: 'Blog', position: 'left'},
|
||||
{ to: 'blog', label: 'Blog', position: 'left' },
|
||||
{
|
||||
href: 'https://github.com/electron/electron',
|
||||
label: 'GitHub',
|
||||
|
|
@ -90,14 +90,12 @@ module.exports = {
|
|||
docs: {
|
||||
sidebarPath: require.resolve('./sidebars.js'),
|
||||
// Please change this to your repo.
|
||||
editUrl:
|
||||
'https://github.com/electron/electronjs.org-new',
|
||||
editUrl: 'https://github.com/electron/electronjs.org-new',
|
||||
},
|
||||
blog: {
|
||||
showReadingTime: true,
|
||||
// Please change this to your repo.
|
||||
editUrl:
|
||||
'https://example.com',
|
||||
editUrl: 'https://example.com',
|
||||
},
|
||||
theme: {
|
||||
customCss: require.resolve('./src/css/custom.css'),
|
||||
|
|
|
|||
13
package.json
13
package.json
|
|
@ -11,7 +11,8 @@
|
|||
"clear": "docusaurus clear",
|
||||
"serve": "docusaurus serve",
|
||||
"write-translations": "docusaurus write-translations",
|
||||
"write-heading-ids": "docusaurus write-heading-ids"
|
||||
"write-heading-ids": "docusaurus write-heading-ids",
|
||||
"prebuild": "node ./scripts/pre-build.js"
|
||||
},
|
||||
"dependencies": {
|
||||
"@docusaurus/core": "2.0.0-alpha.72",
|
||||
|
|
@ -32,5 +33,13 @@
|
|||
"last 1 firefox version",
|
||||
"last 1 safari version"
|
||||
]
|
||||
},
|
||||
"devDependencies": {
|
||||
"del": "^6.0.0",
|
||||
"globby": "^11.0.3",
|
||||
"got": "^11.8.2",
|
||||
"gunzip-maybe": "^1.4.2",
|
||||
"make-dir": "^3.1.0",
|
||||
"tar-stream": "^2.2.0"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,52 @@
|
|||
//@ts-check
|
||||
|
||||
/**
|
||||
* Takes care of downloading the documentation from the
|
||||
* right places, and transform it to make it ready to
|
||||
* be used by docusaurus.
|
||||
*/
|
||||
const path = require('path');
|
||||
const del = require('del');
|
||||
|
||||
const { download } = require('./tasks/download-docs');
|
||||
const { addFrontmatter } = require('./tasks/add-frontmatter');
|
||||
const { createSidebar } = require('./tasks/create-sidebar');
|
||||
const { fixContent } = require('./tasks/md-fixers');
|
||||
|
||||
const DOCS_FOLDER = 'docs';
|
||||
const BLOG_FOLDER = 'blog';
|
||||
// TODO: Figure out the latest release
|
||||
const VERSION = '12-x-y';
|
||||
|
||||
const start = async () => {
|
||||
console.log(`Deleting previous content`);
|
||||
await del(DOCS_FOLDER);
|
||||
await del(BLOG_FOLDER);
|
||||
|
||||
console.log(`Downloading docs for "v${VERSION}"`);
|
||||
await download({
|
||||
target: VERSION,
|
||||
repository: 'electron',
|
||||
destination: DOCS_FOLDER,
|
||||
downloadMatch: 'docs',
|
||||
});
|
||||
|
||||
console.log(`Downloading posts`);
|
||||
await download({
|
||||
target: 'master',
|
||||
repository: 'electronjs.org',
|
||||
destination: BLOG_FOLDER,
|
||||
downloadMatch: 'data/blog',
|
||||
});
|
||||
|
||||
console.log('Adding automatic frontmatter');
|
||||
await addFrontmatter(DOCS_FOLDER);
|
||||
|
||||
console.log('Updating sidebar.js');
|
||||
await createSidebar(DOCS_FOLDER, path.join(process.cwd(), 'sidebars.js'));
|
||||
|
||||
console.log('Fixing markdown');
|
||||
await fixContent(DOCS_FOLDER);
|
||||
};
|
||||
|
||||
start();
|
||||
|
|
@ -0,0 +1,184 @@
|
|||
// @ts-check
|
||||
|
||||
const globby = require('globby');
|
||||
const path = require('path');
|
||||
const fs = require('fs-extra');
|
||||
const DOCS_PATH = 'docs';
|
||||
|
||||
/**
|
||||
*
|
||||
* @param {string} startPath The absolute path to look for
|
||||
* @returns {Promise<Map<string, string>>}
|
||||
*/
|
||||
const getMarkdownFiles = async (startPath) => {
|
||||
const filesPaths = await globby(path.posix.join(startPath, '**/*.md'));
|
||||
|
||||
const files = new Map();
|
||||
for (const filePath of filesPaths) {
|
||||
const content = await fs.readFile(filePath, 'utf-8');
|
||||
files.set(filePath, content);
|
||||
}
|
||||
|
||||
return files;
|
||||
};
|
||||
|
||||
/**
|
||||
* Generates a title using the file name.
|
||||
* This should be used as a last resort.
|
||||
* @param {string} filepath
|
||||
*/
|
||||
const titleFromPath = (filepath) => {
|
||||
const filename = path.basename(filepath);
|
||||
const title = filename
|
||||
// Other logic here
|
||||
.replace(/-/g, ' ');
|
||||
|
||||
return title;
|
||||
};
|
||||
|
||||
/**
|
||||
* Removes markdown links and quotes
|
||||
* @param {string} content
|
||||
*/
|
||||
const cleanUpMarkdown = (content) => {
|
||||
const mdLinkRegex = /\[(.*?)\][([].*?[)\]]/gim;
|
||||
const groups = content.matchAll(mdLinkRegex);
|
||||
let cleanedUp = content;
|
||||
|
||||
if (!groups) {
|
||||
return cleanedUp;
|
||||
}
|
||||
|
||||
for (const group of groups) {
|
||||
const [match, replacement] = group;
|
||||
cleanedUp = cleanedUp.replace(match, replacement);
|
||||
}
|
||||
|
||||
// Other link formats and inline codeblocks
|
||||
cleanedUp = cleanedUp
|
||||
.replace(/\[`/g, '')
|
||||
.replace(/`\]/g, '')
|
||||
.replace(/`/g, '')
|
||||
.trim();
|
||||
|
||||
return cleanedUp;
|
||||
};
|
||||
|
||||
/**
|
||||
* Returns the first paragraph of content (first
|
||||
* occurrence of `\n\n`) without
|
||||
* considering the headers
|
||||
* @param {string} content
|
||||
*/
|
||||
const descriptionFromContent = (content) => {
|
||||
const lines = content.split('\n');
|
||||
|
||||
let description = '';
|
||||
let subHeader = false;
|
||||
let wasPreviousLineEmpty = false;
|
||||
|
||||
for (const line of lines) {
|
||||
const trimmedLine = line.trim();
|
||||
|
||||
// The content of structures is often only bullet lists and no general description
|
||||
if (trimmedLine.startsWith('#') || trimmedLine.startsWith('*')) {
|
||||
if (subHeader) {
|
||||
return cleanUpMarkdown(description.trim());
|
||||
} else {
|
||||
subHeader = true;
|
||||
}
|
||||
} else if (trimmedLine.length === 0) {
|
||||
if (description.length > 0) {
|
||||
return cleanUpMarkdown(description.trim());
|
||||
}
|
||||
} else {
|
||||
description += `${trimmedLine.replace(/^>/, '')} `;
|
||||
wasPreviousLineEmpty = false;
|
||||
}
|
||||
}
|
||||
|
||||
return description;
|
||||
};
|
||||
|
||||
/**
|
||||
*
|
||||
* @param {string} content
|
||||
* @param {string} filepath
|
||||
*/
|
||||
const addFrontMatter = (content, filepath) => {
|
||||
if (content.startsWith('---')) {
|
||||
return content;
|
||||
}
|
||||
|
||||
// Some pages (under API mostly) start with ## instead of #
|
||||
const titleRegex = /^##?\s(.*)$/im;
|
||||
const titleMatches = content.match(titleRegex);
|
||||
const title = titleMatches
|
||||
? titleMatches[1].trim()
|
||||
: titleFromPath(filepath).trim();
|
||||
|
||||
const description = descriptionFromContent(content);
|
||||
|
||||
const mdWithFrontmatter = `---
|
||||
title: "${title}"
|
||||
description: "${description.replace(/"/g, '\\"')}"
|
||||
slug: ${path.basename(filepath, '.md')}
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
${content}`;
|
||||
|
||||
return mdWithFrontmatter;
|
||||
};
|
||||
|
||||
/**
|
||||
* Automatically adds a frontmatter to all the markdown
|
||||
* files under `startPath` using the first heading as
|
||||
* title and paragraph as description.
|
||||
* @param {string} startPath
|
||||
*/
|
||||
const addFrontmatterToAllDocs = async (startPath) => {
|
||||
const files = await getMarkdownFiles(startPath);
|
||||
|
||||
for (const [filepath, content] of files) {
|
||||
const newContent = addFrontMatter(content, filepath);
|
||||
|
||||
await fs.writeFile(filepath, newContent, 'utf-8');
|
||||
}
|
||||
};
|
||||
|
||||
/**
|
||||
* Checks that all markdown files under `startPath` contain
|
||||
* a valid frontmatter.
|
||||
* @param {string} startPath
|
||||
*/
|
||||
const checkFrontmatterInAllDocs = async (startPath) => {
|
||||
// This is the regex used by [markdownlint](https://www.npmjs.com/package/markdownlint#user-content-optionsfrontmatter)
|
||||
// which is used to validate the md files of this project
|
||||
const frontmatterRegex = /((^---\s*$[^]*?^---\s*$)|(^\+\+\+\s*$[^]*?^(\+\+\+|\.\.\.)\s*$)|(^\{\s*$[^]*?^\}\s*$))(\r\n|\r|\n|$)/m;
|
||||
const files = await getMarkdownFiles(startPath);
|
||||
const errors = new Set();
|
||||
|
||||
for (const [filepath, content] of files) {
|
||||
if (!frontmatterRegex.test(content)) {
|
||||
errors.add(filepath);
|
||||
}
|
||||
}
|
||||
|
||||
if (errors.size > 0) {
|
||||
console.error(
|
||||
'The following markdown files do not have a frontmatter section:'
|
||||
);
|
||||
for (const file of errors) {
|
||||
console.error(file);
|
||||
}
|
||||
|
||||
process.exitCode = 1;
|
||||
} else {
|
||||
console.log('All markdown files have a frontmatter section 🙌');
|
||||
}
|
||||
};
|
||||
|
||||
module.exports = {
|
||||
addFrontmatter: addFrontmatterToAllDocs,
|
||||
};
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
//@ts-check
|
||||
|
||||
/**
|
||||
*
|
||||
*/
|
||||
|
||||
const fs = require('fs').promises;
|
||||
const globby = require('globby');
|
||||
|
||||
const ignoredEntries = new Set(['fiddles', 'images']);
|
||||
const defaultCategory = 'docs';
|
||||
const topCategories = new Set(['api', defaultCategory]);
|
||||
|
||||
const sidebar = {
|
||||
docs: [],
|
||||
api: [],
|
||||
};
|
||||
|
||||
/**
|
||||
* @typedef Entry
|
||||
* @property {string} type
|
||||
* @property {string} label
|
||||
* @property {string[]} items
|
||||
*/
|
||||
|
||||
/**
|
||||
* Capitalizes the first letter of each word in title.
|
||||
* @param {string} title
|
||||
*/
|
||||
const capitalize = (title) => {
|
||||
const words = title.split(' ');
|
||||
const capitalizedWords = words.map((word) => {
|
||||
return word[0].toUpperCase() + word.substring(1);
|
||||
});
|
||||
|
||||
return capitalizedWords.join(' ');
|
||||
};
|
||||
|
||||
/**
|
||||
* Creates/updates `sidebars.js` based on:
|
||||
* - Folder structure
|
||||
* - Frontmatter (TODO)
|
||||
* @param {string} root Where the docs are
|
||||
* @param {string} destination The path where `sidebars.js` needs to be created
|
||||
*/
|
||||
const createSidebar = async (root, destination) => {
|
||||
const documents = await globby(`**/*.md`, {
|
||||
onlyFiles: true,
|
||||
cwd: root,
|
||||
});
|
||||
|
||||
/** @type {Map<string, Entry>} */
|
||||
const categories = new Map();
|
||||
for (const document of documents) {
|
||||
const segments = document.split('/');
|
||||
|
||||
// This matches files like `readme.md` and `styleguide.md` that we do not want
|
||||
if (segments.length === 1) {
|
||||
continue;
|
||||
}
|
||||
|
||||
const categoryId = segments[0];
|
||||
|
||||
let category;
|
||||
|
||||
if (!categories.has(categoryId)) {
|
||||
category = {
|
||||
type: 'category',
|
||||
label:
|
||||
categoryId === 'api'
|
||||
? 'modules'
|
||||
: capitalize(categoryId.replace(/-/g, ' ')), // Do better...
|
||||
items: [],
|
||||
};
|
||||
categories.set(categoryId, category);
|
||||
}
|
||||
|
||||
category = categories.get(categoryId);
|
||||
|
||||
category.items.push(document.replace('.md', ''));
|
||||
category.items = category.items.sort();
|
||||
}
|
||||
|
||||
for (const [category, content] of categories) {
|
||||
if (category === 'api') {
|
||||
sidebar.api.push(content);
|
||||
} else {
|
||||
sidebar.docs.push(content);
|
||||
}
|
||||
}
|
||||
|
||||
await fs.writeFile(
|
||||
destination,
|
||||
`module.exports = ${JSON.stringify(sidebar, null, 2)};`,
|
||||
'utf-8'
|
||||
);
|
||||
};
|
||||
|
||||
module.exports = {
|
||||
createSidebar,
|
||||
};
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
{
|
||||
"docs/experimental.md": "docs/api/experimental.md",
|
||||
"docs/faq.md": "docs/resources/faq.md",
|
||||
"docs/glossary.md": "docs/resources/glossary.md",
|
||||
"docs/README.md": "docs/readme.md",
|
||||
"docs/styleguide.md": "docs/styleguide.md",
|
||||
"docs/development/README.md": "docs/contributing/README.md",
|
||||
"docs/development/accessibility.md": "docs/testing-and-debugging/accessibility.md",
|
||||
"docs/development/azure-vm-setup.md": "docs/contributing/azure-vm-setup.md",
|
||||
"docs/development/build-instructions-gn.md": "docs/contributing/build-instructions-gn.md",
|
||||
"docs/development/build-instructions-linux.md": "docs/contributing/build-instructions-linux.md",
|
||||
"docs/development/build-instructions-macos.md": "docs/contributing/build-instructions-macos.md",
|
||||
"docs/development/build-instructions-windows.md": "docs/contributing/build-instructions-windows.md",
|
||||
"docs/development/build-system-overview.md": "docs/contributing/build-system-overview.md",
|
||||
"docs/development/chromium-development.md": "docs/contributing/chromium-development.md",
|
||||
"docs/development/clang-format.md": "docs/contributing/clang-format.md",
|
||||
"docs/development/clang-tidy.md": "docs/contributing/clang-tidy.md",
|
||||
"docs/development/coding-style.md": "docs/contributing/coding-style.md",
|
||||
"docs/development/debug-instructions-windows.md": "docs/contributing/debug-instructions-windows.md",
|
||||
"docs/development/debugging-instructions-macos-xcode.md": "docs/contributing/debugging-instructions-macos-xcode.md",
|
||||
"docs/development/debugging-instructions-macos.md": "docs/contributing/debugging-instructions-macos.md",
|
||||
"docs/development/electron-vs-nwjs.md": "docs/internals/electron-vs-nwjs.md",
|
||||
"docs/development/goma.md": "docs/contributing/goma.md",
|
||||
"docs/development/issues.md": "docs/contributing/issues.md",
|
||||
"docs/development/patches.md": "docs/contributing/patches.md",
|
||||
"docs/development/pull-requests.md": "docs/contributing/pull-requests.md",
|
||||
"docs/development/setting-up-symbol-server.md": "docs/contributing/setting-up-symbol-server.md",
|
||||
"docs/development/source-code-directory-structure.md": "docs/contributing/source-code-directory-structure.md",
|
||||
"docs/development/testing.md": "docs/contributing/testing.md",
|
||||
"docs/development/using-native-node-modules.md": "docs/how-to/using-native-node-modules.md",
|
||||
"docs/development/v8-development.md": "docs/contributing/v8-development.md",
|
||||
"docs/tutorial/accessibility.md": "docs/development/accessibility.md",
|
||||
"docs/tutorial/using-native-node-modules.md": "docs/development/using-native-node-modules.md",
|
||||
"docs/tutorial/application-distribution.md": "docs/distribution/application-distribution.md",
|
||||
"docs/tutorial/code-signing.md": "docs/distribution/code-signing.md",
|
||||
"docs/tutorial/mac-app-store-submission-guide.md": "docs/distribution/mac-app-store-submission-guide.md",
|
||||
"docs/tutorial/snapcraft.md": "docs/distribution/snapcraft.md",
|
||||
"docs/tutorial/windows-store-guide.md": "docs/distribution/windows-store-guide.md",
|
||||
"docs/tutorial/installation.md": "docs/get-started/installation.md",
|
||||
"docs/tutorial/quick-start.md": "docs/get-started/quick-start.md",
|
||||
"docs/tutorial/dark-mode.md": "docs/how-to/dark-mode.md",
|
||||
"docs/tutorial/desktop-environment-integration.md": "docs/how-to/desktop-environment-integration.md",
|
||||
"docs/tutorial/fuses.md": "docs/how-to/fuses.md",
|
||||
"docs/tutorial/in-app-purchases.md": "docs/how-to/in-app-purchases.md",
|
||||
"docs/tutorial/keyboard-shortcuts.md": "docs/how-to/keyboard-shortcuts.md",
|
||||
"docs/tutorial/linux-desktop-actions.md": "docs/how-to/linux-desktop-actions.md",
|
||||
"docs/tutorial/macos-dock.md": "docs/how-to/macos-dock.md",
|
||||
"docs/tutorial/multithreading.md": "docs/how-to/multithreading.md",
|
||||
"docs/tutorial/native-file-drag-drop.md": "docs/how-to/native-file-drag-drop.md",
|
||||
"docs/tutorial/notifications.md": "docs/how-to/notifications.md",
|
||||
"docs/tutorial/offscreen-rendering.md": "docs/how-to/offscreen-rendering.md",
|
||||
"docs/tutorial/online-offline-events.md": "docs/how-to/online-offline-events.md",
|
||||
"docs/tutorial/progress-bar.md": "docs/how-to/progress-bar.md",
|
||||
"docs/tutorial/recent-documents.md": "docs/how-to/recent-documents.md",
|
||||
"docs/tutorial/repl.md": "docs/how-to/repl.md",
|
||||
"docs/tutorial/represented-file.md": "docs/how-to/represented-file.md",
|
||||
"docs/tutorial/spellchecker.md": "docs/how-to/spellchecker.md",
|
||||
"docs/tutorial/using-pepper-flash-plugin.md": "docs/how-to/using-pepper-flash-plugin.md",
|
||||
"docs/tutorial/web-embeds.md": "docs/how-to/web-embeds.md",
|
||||
"docs/tutorial/windows-arm.md": "docs/how-to/windows-arm.md",
|
||||
"docs/tutorial/windows-taskbar.md": "docs/how-to/windows-taskbar.md",
|
||||
"docs/tutorial/message-ports.md": "docs/performance/message-ports.md",
|
||||
"docs/tutorial/performance.md": "docs/performance/performance.md",
|
||||
"docs/tutorial/boilerplates-and-clis.md": "docs/resources/boilerplates-and-clis.md",
|
||||
"docs/breaking-changes.md": "docs/resources/breaking-changes.md",
|
||||
"docs/tutorial/electron-timelines.md": "docs/resources/electron-timelines.md",
|
||||
"docs/tutorial/electron-versioning.md": "docs/resources/electron-versioning.md",
|
||||
"docs/tutorial/support.md": "docs/resources/support.md",
|
||||
"docs/tutorial/context-isolation.md": "docs/security/context-isolation.md",
|
||||
"docs/tutorial/security.md": "docs/security/security.md",
|
||||
"docs/tutorial/application-debugging.md": "docs/testing-and-debugging/application-debugging.md",
|
||||
"docs/tutorial/automated-testing-with-a-custom-driver.md": "docs/testing-and-debugging/automated-testing-with-a-custom-driver.md",
|
||||
"docs/tutorial/debugging-main-process.md": "docs/testing-and-debugging/debugging-main-process.md",
|
||||
"docs/tutorial/debugging-vscode.md": "docs/testing-and-debugging/debugging-vscode.md",
|
||||
"docs/tutorial/devtools-extension.md": "docs/testing-and-debugging/devtools-extension.md",
|
||||
"docs/tutorial/testing-on-headless-ci.md": "docs/testing-and-debugging/testing-on-headless-ci.md",
|
||||
"docs/tutorial/testing-widevine-cdm.md": "docs/testing-and-debugging/testing-widevine-cdm.md",
|
||||
"docs/tutorial/updates.md": "docs/how-to/updates.md",
|
||||
"docs/tutorial/using-selenium-and-webdriver.md": "docs/testing-and-debugging/using-selenium-and-webdriver.md"
|
||||
}
|
||||
|
|
@ -0,0 +1,165 @@
|
|||
//@ts-check
|
||||
const fs = require('fs').promises;
|
||||
|
||||
const path = require('path');
|
||||
const makeDir = require('make-dir');
|
||||
const tar = require('tar-stream');
|
||||
const got = require('got');
|
||||
|
||||
const pathRewrites = require('./docs-reorg.json');
|
||||
const fixedFolders = ['api', 'images', 'fiddles'];
|
||||
|
||||
/**
|
||||
* @typedef DownloadOptions
|
||||
* @type {object}
|
||||
* @property {string} repository - The repository in the electron org to download the contents from
|
||||
* @property {string} destination - The destination absolute path.
|
||||
* @property {string} target - The branch, commit, version. (e.g. `v1.0.0`, `master`)
|
||||
* @property {string} downloadMatch - The math to use to filter the downloaded contents
|
||||
*/
|
||||
|
||||
/**
|
||||
* @typedef Entry
|
||||
* @property {string} filename
|
||||
* @property {string} slug
|
||||
* @property {Buffer} content
|
||||
*/
|
||||
|
||||
/**
|
||||
* Checks if the given folder is one of those that do not have to be
|
||||
* modified
|
||||
* @param {string} folder
|
||||
* @returns
|
||||
*/
|
||||
const isFixedFolder = (folder) => {
|
||||
for (const fixedFolder of fixedFolders) {
|
||||
if (folder.includes(`/${fixedFolder}`)) {
|
||||
return true;
|
||||
}
|
||||
}
|
||||
return false;
|
||||
};
|
||||
|
||||
/**
|
||||
* Returns the right folder where the given document needs to be place
|
||||
* taking into consideration:
|
||||
* 1. If it's a "fixed" folder (api, images, fiddles)
|
||||
* 1. It has an entry in `docs-reorg.json`
|
||||
* 1. Using the default or puts it the default folder ('how-to')
|
||||
* @param {string} destination
|
||||
* @param {string} filename
|
||||
*/
|
||||
const getFinalPath = (destination, filename) => {
|
||||
const relativePath = path.join(destination, filename);
|
||||
|
||||
let finalPath = '';
|
||||
|
||||
if (isFixedFolder(relativePath)) {
|
||||
finalPath = relativePath;
|
||||
} else if (pathRewrites[relativePath]) {
|
||||
finalPath = pathRewrites[relativePath];
|
||||
} else {
|
||||
const basename = path.basename(filename);
|
||||
finalPath = path.join(destination, 'how-to', basename);
|
||||
}
|
||||
|
||||
return path.join(process.cwd(), finalPath);
|
||||
};
|
||||
|
||||
/**
|
||||
* Saves the file on disk creating the necessary folders
|
||||
* @param {Entry[]} files
|
||||
* @param {string} destination
|
||||
*/
|
||||
const saveContents = async (files, destination) => {
|
||||
for (const file of files) {
|
||||
const { content, filename } = file;
|
||||
const finalPath = getFinalPath(destination, filename);
|
||||
|
||||
await makeDir(path.dirname(finalPath));
|
||||
|
||||
await fs.writeFile(finalPath, content);
|
||||
}
|
||||
};
|
||||
|
||||
/**
|
||||
* Downloads the contents of a branch or release from GitHub
|
||||
* @param {DownloadOptions} options
|
||||
*/
|
||||
const downloadFromGitHub = async (options) => {
|
||||
const { repository, target, downloadMatch = '' } = options;
|
||||
|
||||
const tarballUrl = `https://github.com/electron/${repository}/archive/${target}.tar.gz`;
|
||||
|
||||
const contents = [];
|
||||
|
||||
return new Promise((resolve) => {
|
||||
got
|
||||
.stream(tarballUrl)
|
||||
.pipe(require('gunzip-maybe')())
|
||||
.pipe(
|
||||
tar
|
||||
.extract()
|
||||
.on('entry', (header, stream, next) => {
|
||||
header.name = header.name.replace(`${repository}-${target}`, '');
|
||||
|
||||
if (header.type === 'file' && header.name.match(downloadMatch)) {
|
||||
let chunks = [];
|
||||
stream.on('data', (data) => {
|
||||
chunks.push(data);
|
||||
});
|
||||
stream.on('end', () => {
|
||||
const content = Buffer.concat(chunks);
|
||||
contents.push({
|
||||
filename: header.name.replace(`${downloadMatch}/`, ''),
|
||||
slug: path.basename(header.name, '.md'),
|
||||
content,
|
||||
});
|
||||
|
||||
next();
|
||||
});
|
||||
} else {
|
||||
next();
|
||||
}
|
||||
stream.resume();
|
||||
})
|
||||
.on('finish', () => {
|
||||
resolve(contents);
|
||||
})
|
||||
);
|
||||
});
|
||||
};
|
||||
|
||||
/**
|
||||
* Downloads the contents of GitHub repo (branch, release)
|
||||
* with the option to choose the download destination,
|
||||
* filtering by path, and reorganizing the folder structure
|
||||
* as needed.
|
||||
* @param {DownloadOptions} userOptions
|
||||
*/
|
||||
const download = async (userOptions) => {
|
||||
const options = {
|
||||
...{ target: 'master' },
|
||||
...userOptions,
|
||||
};
|
||||
|
||||
const contents = await downloadFromGitHub(options);
|
||||
|
||||
await saveContents(contents, userOptions.destination);
|
||||
};
|
||||
|
||||
/**
|
||||
* Copies the contents of the given folder to the destination,
|
||||
* filtering by path, and reorganizing the folder structure
|
||||
* as needed.
|
||||
* @param {DownloadOptions} userOptions
|
||||
*/
|
||||
const copy = async (userOptions) => {
|
||||
// Load contents
|
||||
// Save contents
|
||||
};
|
||||
|
||||
module.exports = {
|
||||
download,
|
||||
copy,
|
||||
};
|
||||
|
|
@ -0,0 +1,183 @@
|
|||
//@ts-check
|
||||
|
||||
const fs = require('fs').promises;
|
||||
const path = require('path');
|
||||
const globby = require('globby');
|
||||
|
||||
/**
|
||||
* MDX has some problems with strings like `Promise<void>` that need
|
||||
* to be converted to `Promise<void/>`. This scripts makes sure that
|
||||
* the contents of the documents are sanitized so they are ready to
|
||||
* be used by docusaurus.
|
||||
*/
|
||||
|
||||
const keywords = new Set([
|
||||
'any',
|
||||
'Boolean',
|
||||
'Buffer',
|
||||
'Extension',
|
||||
'ExtensionInfo',
|
||||
'Integer',
|
||||
'local',
|
||||
'NativeImage',
|
||||
// TODO: Normalize (nN)umber in the docs
|
||||
'number',
|
||||
'Number',
|
||||
'Object',
|
||||
'port',
|
||||
'Product',
|
||||
'proxyHost',
|
||||
'proxyPort',
|
||||
'proxyScheme',
|
||||
'proxyURL',
|
||||
'proxyURIList',
|
||||
'ServiceWorkerInfo',
|
||||
// TODO: Normalize (sS)tring in the docs
|
||||
'string',
|
||||
'String',
|
||||
'Uint8Array',
|
||||
'unknown',
|
||||
'urlScheme',
|
||||
'void',
|
||||
'webview',
|
||||
]);
|
||||
|
||||
/**
|
||||
* MDX has some problems with strings like `Promise<void>` when they
|
||||
* are out of code blocks.
|
||||
* This happens when declaring the types of the arguments. This method
|
||||
* replaces the closing `>` with the unicode character `>` to
|
||||
* prevent this issue.
|
||||
*
|
||||
* @param {string} doc
|
||||
*/
|
||||
const sanitizeAPI = (doc) => {
|
||||
/**
|
||||
* Matches the following:
|
||||
* > * `userInfo` Record<String, unknown>
|
||||
* ➡ [" * ", "`userInfo` Record<String, unknown>", "userInfo", "Record<String, unknown>", ""]
|
||||
* > * `channel` String
|
||||
* ➡ ["* ", "`channel` String", "channel", "String", ""]
|
||||
* > * `deliverImmediately` Boolean (optional) - `true` to post notifications immediately even when the subscribing app is inactive.
|
||||
* ➡ ["* ", "...", "deliverImmediately", "Boolean (optional) ", "-"] ⚠ Note the trailing space in [3]
|
||||
*/
|
||||
const argumentRegex = /(\s*\*\s+)`([a-zA-Z]+?)`\s([\s\S]+?)($|\s-)/;
|
||||
const lines = doc.split('\n');
|
||||
const newDoc = [];
|
||||
|
||||
for (const line of lines) {
|
||||
const matches = argumentRegex.exec(line);
|
||||
|
||||
if (!matches) {
|
||||
newDoc.push(line);
|
||||
continue;
|
||||
}
|
||||
|
||||
const newLine = line.replace(
|
||||
matches[0],
|
||||
`${matches[1]}\`${matches[2].trim()}\` ${matches[3]
|
||||
.trim()
|
||||
.replace(/>/g, '>')} ${matches[4].trim()}`.trim() // matches[4] could be empty and thus end up with a trailing space
|
||||
);
|
||||
|
||||
newDoc.push(newLine);
|
||||
}
|
||||
|
||||
return newDoc.join('\n');
|
||||
};
|
||||
|
||||
/**
|
||||
* Does a best effort to fix internal links
|
||||
* @param {string} content
|
||||
* @param {Map<string,string>} linksMaps
|
||||
*/
|
||||
const fixLinks = (content, linksMaps) => {
|
||||
/**
|
||||
* This regex should match the following examples:
|
||||
* * [link label]: ./somewhere.md
|
||||
* * [link label]:../anywhere
|
||||
* * [link label]: nowhere
|
||||
* * [link](./somewhere.md)
|
||||
* * [link](../anywhere)
|
||||
* * [link](nowhere)
|
||||
* * [link](https://github.com/electron/electron/blob/HEAD/path-to-file/file.md)
|
||||
* * [link]: https://github.com/electron/electron/
|
||||
* * [link]:https://another.place/
|
||||
*
|
||||
* The 2nd group contains the link.
|
||||
* See https://regex101.com/r/i40SRL/1 for testing
|
||||
*/
|
||||
let updatedContent = content;
|
||||
const mdLinkRegex = /(]:\s*|]\()(\S*?)?(?:\s|$|\))/gi;
|
||||
let val;
|
||||
|
||||
while ((val = mdLinkRegex.exec(content)) !== null) {
|
||||
const link = val[2];
|
||||
const basename = path.basename(link);
|
||||
// Link could be `glossary.md#main-process` and we just need `glossary.md`
|
||||
const parts = basename.split('#');
|
||||
const key = parts.shift();
|
||||
if (linksMaps.has(key)) {
|
||||
const newLink = [linksMaps.get(key), ...parts];
|
||||
const replacement = val[0].replace(val[2], newLink.join('#'));
|
||||
updatedContent = updatedContent.replace(val[0], replacement);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Docusaurus has a problem when the title of an image spawns multiple lines. E.g.:
|
||||
*
|
||||
* ```md
|
||||
* 
|
||||
* ```
|
||||
*
|
||||
* Surprisingly, it has no problem with multiline regular links 🤷♂️
|
||||
* */
|
||||
const multilineImageTitle = /(?:!\[([^\]]+?)\])\(/gm;
|
||||
while ((val = multilineImageTitle.exec(updatedContent)) !== null) {
|
||||
const title = val[1];
|
||||
if (!title.includes('\n')) {
|
||||
continue;
|
||||
}
|
||||
const fixedTitle = title.replace(/\n/g, ' ');
|
||||
updatedContent = updatedContent.replace(val[0], fixedTitle);
|
||||
}
|
||||
|
||||
return updatedContent;
|
||||
};
|
||||
|
||||
/**
|
||||
* Escapes the required characters to avoid issues with MDX and
|
||||
* makes a best effort to fix any internal link.
|
||||
* @param {string} root
|
||||
*/
|
||||
const fixContent = async (root) => {
|
||||
const files = await globby(`**/*.md`, {
|
||||
cwd: root,
|
||||
});
|
||||
|
||||
/**
|
||||
* Filenames in Electron docs are usually unique so best effort
|
||||
* consist on using the filename (basename) to identify the right
|
||||
* place where it should point.
|
||||
*/
|
||||
const linksMaps = new Map();
|
||||
for (const filePath of files) {
|
||||
linksMaps.set(path.basename(filePath), filePath);
|
||||
}
|
||||
|
||||
for (const filePath of files) {
|
||||
const content = await fs.readFile(path.join(root, filePath), 'utf-8');
|
||||
|
||||
let fixedContent = sanitizeAPI(content);
|
||||
|
||||
fixedContent = fixLinks(fixedContent, linksMaps);
|
||||
|
||||
await fs.writeFile(path.join(root, filePath), fixedContent, 'utf-8');
|
||||
}
|
||||
};
|
||||
|
||||
module.exports = {
|
||||
fixContent,
|
||||
};
|
||||
65
sidebars.js
65
sidebars.js
|
|
@ -1,65 +0,0 @@
|
|||
module.exports = {
|
||||
docs: [
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Getting Started',
|
||||
items: [
|
||||
'introduction',
|
||||
'what-is-electron',
|
||||
],
|
||||
},
|
||||
],
|
||||
api: [
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Modules',
|
||||
items: [
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Main Process',
|
||||
items: [
|
||||
'api/accelerator',
|
||||
'api/app',
|
||||
'api/auto-updater'
|
||||
]
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Renderer Process',
|
||||
items: [
|
||||
'api/accelerator',
|
||||
'api/app',
|
||||
'api/auto-updater'
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Custom DOM Elements',
|
||||
items: [
|
||||
'api/accelerator',
|
||||
'api/app',
|
||||
'api/auto-updater'
|
||||
]
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'API Structures',
|
||||
items: [
|
||||
'api/accelerator',
|
||||
'api/app',
|
||||
'api/auto-updater'
|
||||
]
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Chromium and Node.js',
|
||||
items: [
|
||||
'api/accelerator',
|
||||
'api/app',
|
||||
'api/auto-updater'
|
||||
]
|
||||
},
|
||||
]
|
||||
};
|
||||
2913
yarn.lock
2913
yarn.lock
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
Загрузка…
Ссылка в новой задаче