Merge pull request #2672 from atom/jl-docs-tuts
Standardize Docs: Tutorials
This commit is contained in:
Jessica Lord
commit
357dea506a
10 changed files with 173 additions and 147 deletions
|
|
@ -1,9 +1,9 @@
|
|||
# Application distribution
|
||||
# Application Distribution
|
||||
|
||||
To distribute your app with Electron, you should name the folder of your app
|
||||
as `app`, and put it under Electron's resources directory (on OS X it is
|
||||
`Electron.app/Contents/Resources/`, and on Linux and Windows it is
|
||||
`resources/`), like this:
|
||||
To distribute your app with Electron, the folder containing your app should be
|
||||
named `app` and placed under Electron's resources directory (on OS X it is
|
||||
`Electron.app/Contents/Resources/` and on Linux and Windows it is `resources/`),
|
||||
like this:
|
||||
|
||||
On OS X:
|
||||
|
||||
|
|
@ -24,12 +24,12 @@ electron/resources/app
|
|||
```
|
||||
|
||||
Then execute `Electron.app` (or `electron` on Linux, `electron.exe` on Windows),
|
||||
and Electron will start as your app. The `electron` directory would then be
|
||||
your distribution that should be delivered to final users.
|
||||
and Electron will start as your app. The `electron` directory will then be
|
||||
your distribution to deliver to final users.
|
||||
|
||||
## Packaging your app into a file
|
||||
## Packaging Your App into a File
|
||||
|
||||
Apart from shipping your app by copying all its sources files, you can also
|
||||
Apart from shipping your app by copying all of its source files, you can also
|
||||
package your app into an [asar](https://github.com/atom/asar) archive to avoid
|
||||
exposing your app's source code to users.
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ electron/resources/
|
|||
|
||||
More details can be found in [Application packaging](application-packaging.md).
|
||||
|
||||
## Rebranding with downloaded binaries
|
||||
## Rebranding with Downloaded Binaries
|
||||
|
||||
After bundling your app into Electron, you will want to rebrand Electron
|
||||
before distributing it to users.
|
||||
|
|
@ -103,7 +103,7 @@ MyApp.app/Contents
|
|||
|
||||
You can rename the `electron` executable to any name you like.
|
||||
|
||||
## Rebranding by rebuilding Electron from source
|
||||
## Rebranding by Rebuilding Electron from Source
|
||||
|
||||
It is also possible to rebrand Electron by changing the product name and
|
||||
building it from source. To do this you need to modify the `atom.gyp` file and
|
||||
|
|
|
|||
|
|
@ -1,18 +1,19 @@
|
|||
# Application packaging
|
||||
# Application Packaging
|
||||
|
||||
To mitigate [issues](https://github.com/joyent/node/issues/6960) around long path names on Windows, slightly speed up `require` and conceal your source code from cursory inspection you can choose
|
||||
to package your app into an [asar][asar] archive with little changes to your
|
||||
source code.
|
||||
To mitigate [issues](https://github.com/joyent/node/issues/6960) around long
|
||||
path names on Windows, slightly speed up `require` and conceal your source code
|
||||
from cursory inspection, you can choose to package your app into an [asar][asar]
|
||||
archive with little changes to your source code.
|
||||
|
||||
## Generating `asar` archive
|
||||
## Generating `asar` Archive
|
||||
|
||||
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
|
||||
into a single file. Electron can read arbitrary files from it without unpacking
|
||||
the whole file.
|
||||
|
||||
Following is the steps to package your app into an `asar` archive:
|
||||
Steps to package your app into an `asar` archive:
|
||||
|
||||
### 1. Install the asar utility
|
||||
### 1. Install the asar Utility
|
||||
|
||||
```bash
|
||||
$ npm install -g asar
|
||||
|
|
@ -24,9 +25,9 @@ $ npm install -g asar
|
|||
$ asar pack your-app app.asar
|
||||
```
|
||||
|
||||
## Using `asar` archives
|
||||
## Using `asar` Archives
|
||||
|
||||
In Electron there are two sets of APIs: Node APIs provided by Node.js, and Web
|
||||
In Electron there are two sets of APIs: Node APIs provided by Node.js and Web
|
||||
APIs provided by Chromium. Both APIs support reading files from `asar` archives.
|
||||
|
||||
### Node API
|
||||
|
|
@ -77,8 +78,8 @@ win.loadUrl('file:///path/to/example.asar/static/index.html');
|
|||
|
||||
### Web API
|
||||
|
||||
In a web page, files in archive can be requested with the `file:` protocol. Like
|
||||
the Node API, `asar` archives are treated as directories.
|
||||
In a web page, files in an archive can be requested with the `file:` protocol.
|
||||
Like the Node API, `asar` archives are treated as directories.
|
||||
|
||||
For example, to get a file with `$.get`:
|
||||
|
||||
|
|
@ -91,7 +92,7 @@ $.get('file:///path/to/example.asar/file.txt', function(data) {
|
|||
</script>
|
||||
```
|
||||
|
||||
### Treating `asar` archive as normal file
|
||||
### Treating an `asar` Archive as a Normal File
|
||||
|
||||
For some cases like verifying the `asar` archive's checksum, we need to read the
|
||||
content of `asar` archive as file. For this purpose you can use the built-in
|
||||
|
|
@ -108,21 +109,21 @@ Even though we tried hard to make `asar` archives in the Node API work like
|
|||
directories as much as possible, there are still limitations due to the
|
||||
low-level nature of the Node API.
|
||||
|
||||
### Archives are read only
|
||||
### Archives Are Read-only
|
||||
|
||||
The archives can not be modified so all Node APIs that can modify files will not
|
||||
work with `asar` archives.
|
||||
|
||||
### Working directory can not be set to directories in archive
|
||||
### Working Directory Can Not Be Set to Directories in Archive
|
||||
|
||||
Though `asar` archives are treated as directories, there are no actual
|
||||
directories in the filesystem, so you can never set the working directory to
|
||||
directories in `asar` archives, passing them to `cwd` option of some APIs will
|
||||
also cause errors.
|
||||
directories in `asar` archives. Passing them as the `cwd` option of some APIs
|
||||
will also cause errors.
|
||||
|
||||
### Extra unpacking on some APIs
|
||||
### Extra Unpacking on Some APIs
|
||||
|
||||
Most `fs` APIs can read file or get file's information from `asar` archives
|
||||
Most `fs` APIs can read a file or get a file's information from `asar` archives
|
||||
without unpacking, but for some APIs that rely on passing the real file path to
|
||||
underlying system calls, Electron will extract the needed file into a
|
||||
temporary file and pass the path of the temporary file to the APIs to make them
|
||||
|
|
@ -135,14 +136,14 @@ APIs that requires extra unpacking are:
|
|||
* `fs.openSync`
|
||||
* `process.dlopen` - Used by `require` on native modules
|
||||
|
||||
### Fake stat information of `fs.stat`
|
||||
### Fake Stat Information of `fs.stat`
|
||||
|
||||
The `Stats` object returned by `fs.stat` and its friends on files in `asar`
|
||||
archives is generated by guessing, because those files do not exist on the
|
||||
filesystem. So you should not trust the `Stats` object except for getting file
|
||||
size and checking file type.
|
||||
|
||||
## Adding unpacked files in `asar` archive
|
||||
## Adding Unpacked Files in `asar` Archive
|
||||
|
||||
As stated above, some Node APIs will unpack the file to filesystem when
|
||||
calling, apart from the performance issues, it could also lead to false alerts
|
||||
|
|
@ -161,4 +162,3 @@ After running the command, apart from the `app.asar`, there is also an
|
|||
should copy it together with `app.asar` when shipping it to users.
|
||||
|
||||
[asar]: https://github.com/atom/asar
|
||||
|
||||
|
|
|
|||
|
|
@ -1,25 +1,26 @@
|
|||
# Debugging the main process
|
||||
# Debugging the Main Process
|
||||
|
||||
The devtools of browser window can only debug the renderer process scripts.
|
||||
(I.e. the web pages.) In order to provide a way to debug the scripts of
|
||||
the main process, Electron has provided the `--debug` and `--debug-brk`
|
||||
switches.
|
||||
The browser window devtools can only debug the renderer process scripts (i.e.
|
||||
the web pages). In order to provide a way to debug the scripts from the main
|
||||
process, Electron has provided the `--debug` and `--debug-brk` switches.
|
||||
|
||||
## Command line switches
|
||||
## Command Line Switches
|
||||
|
||||
Use the following command line switches to debug Electron's main process:
|
||||
|
||||
### `--debug=[port]`
|
||||
|
||||
When this switch is used Electron would listen for V8 debugger protocol
|
||||
messages on `port`, the `port` is `5858` by default.
|
||||
When this switch is used Electron will listen for V8 debugger protocol
|
||||
messages on `port`. The default `port` is `5858`.
|
||||
|
||||
### `--debug-brk=[port]`
|
||||
|
||||
Like `--debug` but pauses the script on the first line.
|
||||
|
||||
## Use node-inspector for debugging
|
||||
## Use node-inspector for Debugging
|
||||
|
||||
__Note:__ Electron uses node v0.11.13, which currently doesn't work very well
|
||||
with node-inspector, and the main process would crash if you inspect the
|
||||
with node-inspector, and the main process will crash if you inspect the
|
||||
`process` object under node-inspector's console.
|
||||
|
||||
### 1. Start the [node-inspector][node-inspector] server
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# Desktop environment integration
|
||||
# Desktop Environment Integration
|
||||
|
||||
Different operating systems provide different features on integrating desktop
|
||||
applications into their desktop environments. For example, on Windows
|
||||
applications can put shortcuts in the JumpList of task bar, and on Mac
|
||||
Different operating systems provide different features for integrating desktop
|
||||
applications into their desktop environments. For example, on Windows,
|
||||
applications can put shortcuts in the JumpList of task bar, and on Mac,
|
||||
applications can put a custom menu in the dock menu.
|
||||
|
||||
This guide explains how to integrate your application into those desktop
|
||||
|
|
@ -11,7 +11,7 @@ environments with Electron APIs.
|
|||
## Recent documents (Windows & OS X)
|
||||
|
||||
Windows and OS X provide easy access to a list of recent documents opened by
|
||||
the application via JumpList and dock menu.
|
||||
the application via JumpList or dock menu, respectively.
|
||||
|
||||
__JumpList:__
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ __Application dock menu:__
|
|||
|
||||
<img src="https://cloud.githubusercontent.com/assets/639601/5069610/2aa80758-6e97-11e4-8cfb-c1a414a10774.png" height="353" width="428" >
|
||||
|
||||
To add a file to recent documents, you can use
|
||||
To add a file to recent documents, you can use the
|
||||
[app.addRecentDocument][addrecentdocument] API:
|
||||
|
||||
```javascript
|
||||
|
|
@ -36,22 +36,21 @@ the recent documents list:
|
|||
app.clearRecentDocuments();
|
||||
```
|
||||
|
||||
### Windows notes
|
||||
### Windows Notes
|
||||
|
||||
In order to be able to use this feature on Windows, your application has to be
|
||||
registered as a handler of the file type of the document, otherwise the file
|
||||
won't appear in JumpList even after you have added it. You can find everything
|
||||
on registering your application in [Application Registration][app-registration].
|
||||
|
||||
When a user clicks a file from JumpList, a new instance of your application will
|
||||
be started with the path of the file added as a command line argument.
|
||||
When a user clicks a file from the JumpList, a new instance of your application will be started with the path of the file added as a command line argument.
|
||||
|
||||
### OS X notes
|
||||
### OS X Notes
|
||||
|
||||
When a file is requested from the recent documents menu, the `open-file` event
|
||||
of `app` module would be emitted for it.
|
||||
of `app` module will be emitted for it.
|
||||
|
||||
## Custom dock menu (OS X)
|
||||
## Custom Dock Menu (OS X)
|
||||
|
||||
OS X enables developers to specify a custom menu for the dock, which usually
|
||||
contains some shortcuts for commonly used features of your application:
|
||||
|
|
@ -77,7 +76,7 @@ var dockMenu = Menu.buildFromTemplate([
|
|||
app.dock.setMenu(dockMenu);
|
||||
```
|
||||
|
||||
## User tasks (Windows)
|
||||
## User Tasks (Windows)
|
||||
|
||||
On Windows you can specify custom actions in the `Tasks` category of JumpList,
|
||||
as quoted from MSDN:
|
||||
|
|
@ -104,7 +103,7 @@ __Tasks of Internet Explorer:__
|
|||
|
||||
|
||||
Unlike the dock menu in OS X which is a real menu, user tasks in Windows work
|
||||
like application shortcuts that when user clicks a task, a program would be
|
||||
like application shortcuts such that when user clicks a task, a program will be
|
||||
executed with specified arguments.
|
||||
|
||||
To set user tasks for your application, you can use
|
||||
|
|
@ -124,7 +123,7 @@ app.setUserTasks([
|
|||
]);
|
||||
```
|
||||
|
||||
To clean your tasks list, just call `app.setUserTasks` with empty array:
|
||||
To clean your tasks list, just call `app.setUserTasks` with an empty array:
|
||||
|
||||
```javascript
|
||||
app.setUserTasks([]);
|
||||
|
|
@ -136,9 +135,9 @@ uninstalled.
|
|||
|
||||
## Thumbnail Toolbars
|
||||
|
||||
On Windows, you can add a thumbnail toolbar with specified buttons in a taskbar
|
||||
layout of an application window. It provides users a way to access to a particualr
|
||||
window's command without restoring or activating the window.
|
||||
On Windows you can add a thumbnail toolbar with specified buttons in a taskbar
|
||||
layout of an application window. It provides users a way to access to a
|
||||
particular window's command without restoring or activating the window.
|
||||
|
||||
From MSDN, it's illustrated:
|
||||
|
||||
|
|
@ -187,18 +186,18 @@ with an empty array:
|
|||
win.setThumbarButtons([]);
|
||||
```
|
||||
|
||||
## Unity launcher shortcuts (Linux)
|
||||
## Unity Launcher Shortcuts (Linux)
|
||||
|
||||
In Unity, you can add custom entries to its launcher via modifying `.desktop`
|
||||
file, see [Adding shortcuts to a launcher][unity-launcher].
|
||||
In Unity, you can add custom entries to its launcher via modifying the `.desktop`
|
||||
file, see [Adding Shortcuts to a Launcher][unity-launcher].
|
||||
|
||||
__Launcher shortcuts of Audacious:__
|
||||
|
||||
|
||||
|
||||
## Progress bar in taskbar (Windows & Unity)
|
||||
## Progress Bar in Taskbar (Windows & Unity)
|
||||
|
||||
On Windows, a taskbar button can be used to display a progress bar. This enables
|
||||
On Windows a taskbar button can be used to display a progress bar. This enables
|
||||
a window to provide progress information to the user without the user having to
|
||||
switch to the window itself.
|
||||
|
||||
|
|
@ -221,10 +220,10 @@ var window = new BrowserWindow({...});
|
|||
window.setProgressBar(0.5);
|
||||
```
|
||||
|
||||
## Represented file of window (OS X)
|
||||
## Represented File of Window (OS X)
|
||||
|
||||
On OS X a window can set its represented file, so the file's icon can show in
|
||||
the title bar, and when users Command-Click or Control-Click on the tile a path
|
||||
the title bar and when users Command-Click or Control-Click on the tile a path
|
||||
popup will show.
|
||||
|
||||
You can also set the edited state of a window so that the file icon can indicate
|
||||
|
|
|
|||
|
|
@ -1,52 +1,57 @@
|
|||
# DevTools extension
|
||||
# DevTools Extension
|
||||
|
||||
To make debugging easier, Electron has basic support for
|
||||
To make debugging easier, Electron has basic support for the
|
||||
[Chrome DevTools Extension][devtools-extension].
|
||||
|
||||
For most devtools extensions, you can simply download the source code and use
|
||||
the `BrowserWindow.addDevToolsExtension` API to load them, the loaded extensions
|
||||
For most DevTools extensions you can simply download the source code and use
|
||||
the `BrowserWindow.addDevToolsExtension` API to load them. The loaded extensions
|
||||
will be remembered so you don't need to call the API every time when creating
|
||||
a window.
|
||||
|
||||
For example to use the [React DevTools Extension](https://github.com/facebook/react-devtools), first you need to download its
|
||||
source code:
|
||||
For example, to use the [React DevTools Extension](https://github.com/facebook/react-devtools)
|
||||
, first you need to download its source code:
|
||||
|
||||
```bash
|
||||
$ cd /some-directory
|
||||
$ git clone --recursive https://github.com/facebook/react-devtools.git
|
||||
```
|
||||
|
||||
Then you can load the extension in Electron by opening devtools in any window,
|
||||
and then running the following code in the devtools console:
|
||||
Then you can load the extension in Electron by opening DevTools in any window,
|
||||
and running the following code in the DevTools console:
|
||||
|
||||
```javascript
|
||||
require('remote').require('browser-window').addDevToolsExtension('/some-directory/react-devtools');
|
||||
```
|
||||
|
||||
To unload the extension, you can call `BrowserWindow.removeDevToolsExtension`
|
||||
API with its name and it will not load the next time you open the devtools:
|
||||
To unload the extension, you can call the `BrowserWindow.removeDevToolsExtension`
|
||||
API with its name and it will not load the next time you open the DevTools:
|
||||
|
||||
```javascript
|
||||
require('remote').require('browser-window').removeDevToolsExtension('React Developer Tools');
|
||||
```
|
||||
|
||||
## Format of devtools extension
|
||||
## Format of DevTools Extension
|
||||
|
||||
Ideally all devtools extension written for Chrome browser can be loaded by
|
||||
Electron, but they have to be in a plain directory, for those packaged `crx`
|
||||
extensions, there is no way for Electron to load them unless you find a way to
|
||||
extract them into a directory.
|
||||
Ideally all DevTools extensions written for the Chrome browser can be loaded by
|
||||
Electron, but they have to be in a plain directory. For those packaged with
|
||||
`crx` extensions, there is no way for Electron to load them unless you find a
|
||||
way to extract them into a directory.
|
||||
|
||||
## Background pages
|
||||
## Background Pages
|
||||
|
||||
Currently Electron doesn't support the background pages feature in chrome extensions,
|
||||
so for some devtools extensions that rely on this feature, they may not work in Electron.
|
||||
Currently Electron doesn't support the background pages feature in Chrome
|
||||
extensions, so some DevTools extensions that rely on this feature may
|
||||
not work in Electron.
|
||||
|
||||
## `chrome.*` APIs
|
||||
|
||||
Some chrome extensions use `chrome.*` APIs for some features, there has been some
|
||||
effort to implement those APIs in Electron, however not all are implemented.
|
||||
Some Chrome extensions may use `chrome.*` APIs for features and while there has
|
||||
been some effort to implement those APIs in Electron, not all have been
|
||||
implemented.
|
||||
|
||||
Given that not all `chrome.*` APIs are implemented if the devtools extension is using APIs other than `chrome.devtools.*`, the extension is very likely not to work. You can report failing extensions in the issue tracker so that we can add support for those APIs.
|
||||
Given that not all `chrome.*` APIs are implemented if the DevTools extension is
|
||||
using APIs other than `chrome.devtools.*`, the extension is very likely not to
|
||||
work. You can report failing extensions in the issue tracker so that we can add
|
||||
support for those APIs.
|
||||
|
||||
[devtools-extension]: https://developer.chrome.com/extensions/devtools
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ _online-status.html_
|
|||
</html>
|
||||
```
|
||||
|
||||
There may be instances where one wants to respond to these events in the
|
||||
There may be instances where you want to respond to these events in the
|
||||
main process as well. The main process however does not have a
|
||||
`navigator` object and thus cannot detect these events directly. Using
|
||||
Electron's inter-process communication utilities, the events can be forwarded
|
||||
|
|
|
|||
|
|
@ -1,20 +1,21 @@
|
|||
# Quick start
|
||||
# Quick Start
|
||||
|
||||
## Introduction
|
||||
Electron enables you to create desktop applications with pure JavaScript by
|
||||
providing a runtime with rich native (operating system) APIs. You could see it
|
||||
as a variant of the io.js runtime that is focused on desktop applications
|
||||
instead of web servers.
|
||||
|
||||
Electron enables you to create desktop applications with pure JavaScript by providing a runtime with rich native APIs. You could see it as a variant of the io.js runtime which is focused on desktop applications instead of web servers.
|
||||
This doesn't mean Electron is a JavaScript binding to graphical user interface
|
||||
(GUI) libraries. Instead, Electron uses web pages as its GUI, so you could also
|
||||
see it as a minimal Chromium browser, controlled by JavaScript.
|
||||
|
||||
This doesn't mean Electron is a JavaScript binding to GUI libraries. Instead,
|
||||
Electron uses web pages as its GUI, so you could also see it as a minimal
|
||||
Chromium browser, controlled by JavaScript.
|
||||
|
||||
### Main process
|
||||
### Main Process
|
||||
|
||||
In Electron, the process that runs `package.json`'s `main` script is called
|
||||
__the main process__. The script that runs in the main process can display a GUI by
|
||||
creating web pages.
|
||||
__the main process__. The script that runs in the main process can display a GUI
|
||||
by creating web pages.
|
||||
|
||||
### Renderer process
|
||||
### Renderer Process
|
||||
|
||||
Since Electron uses Chromium for displaying web pages, Chromium's
|
||||
multi-process architecture is also used. Each web page in Electron runs in
|
||||
|
|
@ -24,28 +25,30 @@ 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
|
||||
io.js APIs in web pages allowing lower level operating system interactions.
|
||||
|
||||
### Differences between main process and renderer process
|
||||
### Differences Between Main Process and Renderer Process
|
||||
|
||||
The main process creates web pages by creating `BrowserWindow` instances. Each `BrowserWindow` instance runs the web page in its own renderer process. When a `BrowserWindow` instance is destroyed, the corresponding renderer process
|
||||
The main process creates web pages by creating `BrowserWindow` instances. Each
|
||||
`BrowserWindow` instance runs the web page in its own renderer process. When a
|
||||
`BrowserWindow` instance is destroyed, the corresponding renderer process
|
||||
is also terminated.
|
||||
|
||||
The main process manages all web pages and their corresponding renderer
|
||||
processes. Each renderer process is isolated and only cares
|
||||
about the web page running in it.
|
||||
|
||||
In web pages, it is not allowed to call native GUI related APIs because managing
|
||||
native GUI resources in web pages is very dangerous and it is easy to leak resources.
|
||||
If you want to perform GUI operations in a web page, the renderer process of the web
|
||||
page must communicate with the main process to request the main process perform those
|
||||
operations.
|
||||
In web pages, calling native GUI related APIs is not allowed because managing
|
||||
native GUI resources in web pages is very dangerous and it is easy to leak
|
||||
resources. If you want to perform GUI operations in a web page, the renderer
|
||||
process of the web page must communicate with the main process to request that
|
||||
the main process perform those operations.
|
||||
|
||||
In Electron, we have provided the [ipc](../api/ipc-renderer.md) module for
|
||||
communication between main process and renderer process. And there is also a
|
||||
communication between the main process and renderer process. There is also a
|
||||
[remote](../api/remote.md) module for RPC style communication.
|
||||
|
||||
## Write your first Electron app
|
||||
## Write your First Electron App
|
||||
|
||||
Generally, an Electron app would be structured like this:
|
||||
Generally, an Electron app is structured like this:
|
||||
|
||||
```text
|
||||
your-app/
|
||||
|
|
@ -56,7 +59,7 @@ your-app/
|
|||
|
||||
The format of `package.json` is exactly the same as that of Node's modules, and
|
||||
the script specified by the `main` field is the startup script of your app,
|
||||
which will run on the main process. An example of your `package.json` might look
|
||||
which will run the main process. An example of your `package.json` might look
|
||||
like this:
|
||||
|
||||
```json
|
||||
|
|
@ -81,7 +84,7 @@ var BrowserWindow = require('browser-window'); // Module to create native brows
|
|||
require('crash-reporter').start();
|
||||
|
||||
// Keep a global reference of the window object, if you don't, the window will
|
||||
// be closed automatically when the JavaScript object is GCed.
|
||||
// be closed automatically when the JavaScript object is garbage collected.
|
||||
var mainWindow = null;
|
||||
|
||||
// Quit when all windows are closed.
|
||||
|
|
@ -102,7 +105,7 @@ app.on('ready', function() {
|
|||
// and load the index.html of the app.
|
||||
mainWindow.loadUrl('file://' + __dirname + '/index.html');
|
||||
|
||||
// Open the devtools.
|
||||
// Open the DevTools.
|
||||
mainWindow.openDevTools();
|
||||
|
||||
// Emitted when the window is closed.
|
||||
|
|
@ -138,6 +141,7 @@ you'll probably want to try running your app locally to test it and make sure it
|
|||
working as expected.
|
||||
|
||||
### electron-prebuilt
|
||||
|
||||
If you've installed `electron-prebuilt` globally with `npm`, then you need only
|
||||
run the following in your app's source directory:
|
||||
|
||||
|
|
@ -152,6 +156,7 @@ If you've installed it locally, then run:
|
|||
```
|
||||
|
||||
### Manually Downloaded Electron Binary
|
||||
|
||||
If you downloaded Electron manually, you can also just use the included
|
||||
binary to execute your app directly.
|
||||
|
||||
|
|
@ -177,6 +182,7 @@ $ ./Electron.app/Contents/MacOS/Electron your-app/
|
|||
it from [here](https://github.com/atom/electron/releases).
|
||||
|
||||
### Run as a distribution
|
||||
|
||||
After you're done writing your app, you can create a distribution by
|
||||
following the [Application distribution](./application-distribution.md) guide
|
||||
following the [Application Distribution](./application-distribution.md) guide
|
||||
and then executing the packaged app.
|
||||
|
|
|
|||
|
|
@ -1,22 +1,25 @@
|
|||
# Using native Node modules
|
||||
# Using Native Node Modules
|
||||
|
||||
The native Node modules are supported by Electron, but since Electron is
|
||||
using a different V8 version from official Node, you have to manually specify
|
||||
the location of Electron's headers when building native modules.
|
||||
|
||||
## Native Node module compatibility
|
||||
## Native Node Module Compatibility
|
||||
|
||||
Since Node v0.11.x there were vital changes in the V8 API. So generally all
|
||||
native modules written for Node v0.10.x wouldn't work for newer Node or io.js versions. And
|
||||
because Electron internally uses __io.js v3.1.0__, it carries with the same
|
||||
problem.
|
||||
native modules written for Node v0.10.x won't work for newer Node or io.js
|
||||
versions. And because Electron internally uses __io.js v3.1.0__, it has the
|
||||
same problem.
|
||||
|
||||
To solve this, you should use modules that support Node v0.11.x or later,
|
||||
[many modules](https://www.npmjs.org/browse/depended/nan) do support both now.
|
||||
For old modules that only support Node v0.10.x, you should use the
|
||||
[nan](https://github.com/rvagg/nan) module to port it to v0.11.x or later versions of Node or io.js.
|
||||
[nan](https://github.com/rvagg/nan) module to port it to v0.11.x or later
|
||||
versions of Node or io.js.
|
||||
|
||||
## How to install native modules
|
||||
## How to Install Native Modules
|
||||
|
||||
Three ways to install native modules:
|
||||
|
||||
### The Easy Way
|
||||
|
||||
|
|
@ -27,11 +30,11 @@ which handles the manual steps of downloading headers and building native module
|
|||
```sh
|
||||
npm install --save-dev electron-rebuild
|
||||
|
||||
# Every time you run npm install, run this too
|
||||
# Every time you run npm install, run this
|
||||
./node_modules/.bin/electron-rebuild
|
||||
```
|
||||
|
||||
### The node-gyp way
|
||||
### The node-gyp Way
|
||||
|
||||
To build Node modules with headers of Electron, you need to tell `node-gyp`
|
||||
where to download headers and which version to use:
|
||||
|
|
@ -46,9 +49,9 @@ The `HOME=~/.electron-gyp` changes where to find development headers. The
|
|||
where to download the headers. The `--arch=x64` says the module is built for
|
||||
64bit system.
|
||||
|
||||
### The npm way
|
||||
### The npm Way
|
||||
|
||||
You can also use `npm` to install modules, the steps are exactly the same with
|
||||
You can also use `npm` to install modules. The steps are exactly the same with
|
||||
Node modules, except that you need to setup some environment variables:
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -1,14 +1,22 @@
|
|||
# Using Pepper Flash Plugin
|
||||
|
||||
Pepper flash plugin is now supported. To use pepper flash plugin in Electron, you should manually specify the location of pepper flash plugin and then enable it in your application.
|
||||
Electron now supports the Pepper Flash plugin. To use the Pepper Flash plugin in
|
||||
Electron, you should manually specify the location of the Pepper Flash plugin
|
||||
and then enable it in your application.
|
||||
|
||||
## Prepare a copy of flash plugin
|
||||
## Prepare a Copy of Flash Plugin
|
||||
|
||||
On OS X and Linux, the detail of pepper flash plugin can be found by navigating `chrome://plugins` in Chrome browser. Its location and version are useful for electron's pepper flash support. You can also copy it to anywhere else.
|
||||
On OS X and Linux, the details of the Pepper Flash plugin can be found by
|
||||
navigating to `chrome://plugins` in the Chrome browser. Its location and version
|
||||
are useful for Electron's Pepper Flash support. You can also copy it to another
|
||||
location.
|
||||
|
||||
## Add Electron switch
|
||||
## Add Electron Switch
|
||||
|
||||
You can directly add `--ppapi-flash-path` and `ppapi-flash-version` to electron commandline or by `app.commandLine.appendSwitch` method before app ready event. Also, add the `plugins` switch of `browser-window`. For example,
|
||||
You can directly add `--ppapi-flash-path` and `ppapi-flash-version` to the
|
||||
Electron command line or by using the `app.commandLine.appendSwitch` method
|
||||
before the app ready event. Also, add the `plugins` switch of `browser-window`.
|
||||
For example:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
|
|
@ -50,8 +58,10 @@ app.on('ready', function() {
|
|||
});
|
||||
```
|
||||
|
||||
## Enable flash plugin in a `<webview>` tag
|
||||
## Enable Flash Plugin in a `<webview>` Tag
|
||||
|
||||
Add `plugins` attribute to `<webview>` tag.
|
||||
|
||||
```html
|
||||
<webview src="http://www.adobe.com/software/flash/about/" plugins></webview>
|
||||
```
|
||||
|
|
|
|||
|
|
@ -8,15 +8,15 @@ From [ChromeDriver - WebDriver for Chrome][chrome-driver]:
|
|||
> implements WebDriver's wire protocol for Chromium. It is being developed by
|
||||
> members of the Chromium and WebDriver teams.
|
||||
|
||||
In order to use `chromedriver` together with Electron you have to tell it where to
|
||||
find Electron and make it think Electron is Chrome browser.
|
||||
In order to use `chromedriver` with Electron you have to tell it where to
|
||||
find Electron and make it think Electron is the Chrome browser.
|
||||
|
||||
## Setting up with WebDriverJs
|
||||
|
||||
[WebDriverJs](https://code.google.com/p/selenium/wiki/WebDriverJs) provided
|
||||
[WebDriverJs](https://code.google.com/p/selenium/wiki/WebDriverJs) provides
|
||||
a Node package for testing with web driver, we will use it as an example.
|
||||
|
||||
### 1. Start chrome driver
|
||||
### 1. Start ChromeDriver
|
||||
|
||||
First you need to download the `chromedriver` binary, and run it:
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Remember the port number `9515`, which will be used later
|
|||
$ npm install selenium-webdriver
|
||||
```
|
||||
|
||||
### 3. Connect to chrome driver
|
||||
### 3. Connect to ChromeDriver
|
||||
|
||||
The usage of `selenium-webdriver` with Electron is basically the same with
|
||||
upstream, except that you have to manually specify how to connect chrome driver
|
||||
|
|
@ -66,9 +66,10 @@ driver.quit();
|
|||
|
||||
## Setting up with WebdriverIO
|
||||
|
||||
[WebdriverIO](http://webdriver.io/) provides a Node package for testing with web driver.
|
||||
[WebdriverIO](http://webdriver.io/) provides a Node package for testing with web
|
||||
driver.
|
||||
|
||||
### 1. Start chrome driver
|
||||
### 1. Start ChromeDriver
|
||||
|
||||
First you need to download the `chromedriver` binary, and run it:
|
||||
|
||||
|
|
@ -87,6 +88,7 @@ $ npm install webdriverio
|
|||
```
|
||||
|
||||
### 3. Connect to chrome driver
|
||||
|
||||
```javascript
|
||||
var webdriverio = require('webdriverio');
|
||||
var options = {
|
||||
|
|
@ -113,8 +115,8 @@ client
|
|||
|
||||
## Workflow
|
||||
|
||||
To test your application without rebuilding Electron, simply [place](https://github.com/atom/electron/blob/master/docs/tutorial/application-distribution.md) your app source into Electron's resource directory.
|
||||
To test your application without rebuilding Electron, simply
|
||||
[place](https://github.com/atom/electron/blob/master/docs/tutorial/application-distribution.md)
|
||||
your app source into Electron's resource directory.
|
||||
|
||||
[chrome-driver]: https://sites.google.com/a/chromium.org/chromedriver/
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue