docs: Atom Shell => Electron
This commit is contained in:
Cheng Zhao
parent
d878bd33d7
commit
d2682233fd
29 changed files with 132 additions and 130 deletions
|
|
@ -23,14 +23,14 @@ Under most cases you should just do everything in `ready` event.
|
|||
|
||||
## Event: ready
|
||||
|
||||
Emitted when atom-shell has done everything initialization.
|
||||
Emitted when Electron has done everything initialization.
|
||||
|
||||
## Event: window-all-closed
|
||||
|
||||
Emitted when all windows have been closed.
|
||||
|
||||
This event is only emitted when the application is not going to quit. If a
|
||||
user pressed `Cmd + Q`, or the developer called `app.quit()`, atom-shell would
|
||||
user pressed `Cmd + Q`, or the developer called `app.quit()`, Electron would
|
||||
first try to close all windows and then emit the `will-quit` event, and in
|
||||
this case the `window-all-closed` would not be emitted.
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ used.
|
|||
Usually the `name` field of `package.json` is a short lowercased name, according
|
||||
to the spec of npm modules. So usually you should also specify a `productName`
|
||||
field, which is your application's full capitalized name, and it will be
|
||||
preferred over `name` by atom-shell.
|
||||
preferred over `name` by Electron.
|
||||
|
||||
## app.resolveProxy(url, callback)
|
||||
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ You can also create a window without chrome by using
|
|||
* `extra-plugin-dirs` Array - Array of paths that would be searched for
|
||||
plugins. Note that if you want to add a directory under your app, you
|
||||
should use `__dirname` or `process.resourcesPath` to join the paths to
|
||||
make them absolute, using relative paths would make atom-shell search
|
||||
make them absolute, using relative paths would make Electron search
|
||||
under current working directory.
|
||||
* `experimental-features` Boolean
|
||||
* `experimental-canvas-features` Boolean
|
||||
|
|
@ -116,7 +116,7 @@ would cancel the close.
|
|||
|
||||
Usually you would want to use the `beforeunload` handler to decide whether the
|
||||
window should be closed, which will also be called when the window is
|
||||
reloaded. In atom-shell, returning an empty string or `false` would cancel the
|
||||
reloaded. In Electron, returning an empty string or `false` would cancel the
|
||||
close. An example is:
|
||||
|
||||
```javascript
|
||||
|
|
@ -124,7 +124,7 @@ window.onbeforeunload = function(e) {
|
|||
console.log('I do not want to be closed');
|
||||
|
||||
// Unlike usual browsers, in which a string should be returned and the user is
|
||||
// prompted to confirm the page unload. atom-shell gives the power completely
|
||||
// prompted to confirm the page unload. Electron gives the power completely
|
||||
// to the developers, return empty string or false would prevent the unloading
|
||||
// now. You can also use the dialog API to let user confirm it.
|
||||
return false;
|
||||
|
|
@ -512,7 +512,7 @@ process.
|
|||
* `printBackground` Boolean - Also prints the background color and image of
|
||||
the web page, defaults to `false`.
|
||||
|
||||
Prints window's web page. When `silent` is set to `false`, atom-shell will pick
|
||||
Prints window's web page. When `silent` is set to `false`, Electron will pick
|
||||
up system's default printer and default settings for printing.
|
||||
|
||||
Calling `window.print()` in web page is equivalent to call
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Supported Chrome command line switches
|
||||
|
||||
Following command lines switches in Chrome browser are also Supported in
|
||||
atom-shell, you can use [app.commandLine.appendSwitch][append-switch] to append
|
||||
Electron, you can use [app.commandLine.appendSwitch][append-switch] to append
|
||||
them in your app's main script before the [ready][ready] event of [app][app]
|
||||
module is emitted:
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ crashReporter.start({
|
|||
## crashReporter.start(options)
|
||||
|
||||
* `options` Object
|
||||
* `productName` String, default: Atom-Shell
|
||||
* `productName` String, default: Electron
|
||||
* `companyName` String, default: GitHub, Inc
|
||||
* `submitUrl` String, default: http://54.249.141.255:1127/post
|
||||
* URL that crash reports would be sent to as POST
|
||||
|
|
@ -36,14 +36,14 @@ sent or the crash reporter is not started, `null` will be returned.
|
|||
|
||||
The crash reporter will send the following data to the `submitUrl` as `POST`:
|
||||
|
||||
* `rept` String - e.g. 'atom-shell-crash-service'
|
||||
* `ver` String - The version of atom-shell
|
||||
* `rept` String - e.g. 'electron-crash-service'
|
||||
* `ver` String - The version of Electron
|
||||
* `platform` String - e.g. 'win32'
|
||||
* `process_type` String - e.g. 'renderer'
|
||||
* `ptime` Number
|
||||
* `_version` String - The version in `package.json`
|
||||
* `_productName` String - The product name in the crashReporter `options` object
|
||||
* `prod` String - Name of the underlying product. In this case Atom-Shell
|
||||
* `prod` String - Name of the underlying product. In this case Electron
|
||||
* `_companyName` String - The company name in the crashReporter `options` object
|
||||
* `upload_file_minidump` File - The crashreport as file
|
||||
* All level one properties of the `extra` object in the crashReporter `options` object
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# `File` object
|
||||
|
||||
The DOM's File interface provides abstraction around native files, in order to
|
||||
let users work on native files directly with HTML5 file API, atom-shell has
|
||||
let users work on native files directly with HTML5 file API, Electron has
|
||||
added a `path` attribute to `File` interface which exposes the file's real path
|
||||
on filesystem.
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ var win = new BrowserWindow({ transparent: true, frame: false });
|
|||
## Draggable region
|
||||
|
||||
By default, the frameless window is non-draggable. Apps need to specify
|
||||
`-webkit-app-region: drag` in CSS to tell atom-shell which regions are draggable
|
||||
`-webkit-app-region: drag` in CSS to tell Electron which regions are draggable
|
||||
(like the OS's standard titlebar), and apps can also use
|
||||
`-webkit-app-region: no-drag` to exclude the non-draggable area from the
|
||||
draggable region. Note that only rectangular shape is currently supported.
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@ Linux, and here are some notes on making your app's menu more native-like.
|
|||
|
||||
On OS X there are many system defined standard menus, like the `Services` and
|
||||
`Windows` menus. To make your menu a standard menu, you can just set your menu's
|
||||
label to one of followings, and atom-shell will recognize them and make them
|
||||
label to one of followings, and Electron will recognize them and make them
|
||||
become standard menus:
|
||||
|
||||
* `Window`
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# NativeImage
|
||||
|
||||
In atom-shell for the APIs that take images, you can pass either file paths or
|
||||
In Electron for the APIs that take images, you can pass either file paths or
|
||||
`NativeImage` instances. When passing `null`, an empty image will be used.
|
||||
|
||||
For example when creating tray or setting window's icon, you can pass image's
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
# Process object
|
||||
|
||||
The `process` object in atom-shell has following differences between the one in
|
||||
The `process` object in Electron has following differences between the one in
|
||||
upstream node:
|
||||
|
||||
* `process.type` String - Process's type, can be `browser` (i.e. main process) or `renderer`.
|
||||
* `process.versions['atom-shell']` String - Version of atom-shell.
|
||||
* `process.versions['electron']` String - Version of Electron.
|
||||
* `process.versions['chrome']` String - Version of Chromium.
|
||||
* `process.resourcesPath` String - Path to JavaScript source code.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
The `remote` module provides a simple way to do inter-process communication
|
||||
between the renderer process and the main process.
|
||||
|
||||
In atom-shell, only GUI-related modules are available in the renderer process.
|
||||
In Electron, only GUI-related modules are available in the renderer process.
|
||||
Without the `remote` module, users who wanted to call a main process API in
|
||||
the renderer process would have to explicitly send inter-process messages
|
||||
to the main process. With the `remote` module, users can invoke methods of
|
||||
|
|
@ -35,7 +35,7 @@ corresponding remote object in the renderer process, namely the `win` object.
|
|||
|
||||
## Lifetime of remote objects
|
||||
|
||||
Atom-shell makes sure that as long as the remote object in the renderer process
|
||||
Electron makes sure that as long as the remote object in the renderer process
|
||||
lives (in other words, has not been garbage collected), the corresponding object
|
||||
in the main process would never be released. When the remote object has been
|
||||
garbage collected, the corresponding object in the main process would be
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Synopsis
|
||||
|
||||
All [node.js's built-in modules](http://nodejs.org/api/) are available in
|
||||
atom-shell, and third-party node modules are fully supported too (including the
|
||||
Electron, and third-party node modules are fully supported too (including the
|
||||
[native modules](../tutorial/using-native-node-modules.md)).
|
||||
|
||||
Atom-shell also provides some extra built-in modules for developing native
|
||||
Electron also provides some extra built-in modules for developing native
|
||||
desktop applications. Some modules are only available on the main process, some
|
||||
are only available on the renderer process, and some can be used on both processes.
|
||||
The basic rule is: if a module is GUI or low-level system related, then it should
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# `<webview>` tag
|
||||
|
||||
Use the `webview` tag to embed 'guest' content (such as web pages) in your
|
||||
atom-shell app. The guest content is contained within the `webview` container;
|
||||
Electron app. The guest content is contained within the `webview` container;
|
||||
an embedder page within your app controls how the guest content is laid out and
|
||||
rendered.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,48 +1,50 @@
|
|||
# Technical differences to NW.js (formerly node-webkit)
|
||||
|
||||
Like NW.js, atom-shell provides a platform to write desktop applications
|
||||
__Note: Electron was previously named Atom Shell.__
|
||||
|
||||
Like NW.js, Electron provides a platform to write desktop applications
|
||||
with JavaScript and HTML, and has Node integration to grant access to low level
|
||||
system in web pages.
|
||||
|
||||
But there are also fundamental differences between the two projects that make
|
||||
atom-shell a completely separate product from NW.js:
|
||||
Electron a completely separate product from NW.js:
|
||||
|
||||
**1. Entry of application**
|
||||
__1. Entry of application__
|
||||
|
||||
In NW.js, the main entry of an application is a web page, you specify a
|
||||
main page in the `package.json` and it would be opened in a browser window as
|
||||
the application's main window.
|
||||
|
||||
While in atom-shell, the entry point is a JavaScript script, instead of
|
||||
While in Electron, the entry point is a JavaScript script, instead of
|
||||
providing a URL directly, you need to manually create a browser window and load
|
||||
html file in it with corresponding API. You also need to listen to window events
|
||||
to decide when to quit the application.
|
||||
|
||||
So atom-shell works more like the Node.js runtime, and APIs are more low level,
|
||||
you can also use atom-shell for web testing purpose like
|
||||
So Electron works more like the Node.js runtime, and APIs are more low level,
|
||||
you can also use Electron for web testing purpose like
|
||||
[phantomjs](http://phantomjs.org/).
|
||||
|
||||
**2. Build system**
|
||||
__2. Build system__
|
||||
|
||||
In order to avoid the complexity of building the whole Chromium, atom-shell uses
|
||||
In order to avoid the complexity of building the whole Chromium, Electron uses
|
||||
[libchromiumcontent](https://github.com/brightray/libchromiumcontent) to access
|
||||
Chromium's Content API, libchromiumcontent is a single, shared library that
|
||||
includes the Chromium Content module and all its dependencies. So users don't
|
||||
need a powerful machine to build atom-shell.
|
||||
need a powerful machine to build Electron.
|
||||
|
||||
**3. Node integration**
|
||||
__3. Node integration__
|
||||
|
||||
In NW.js, the Node integration in web pages requires patching Chromium to
|
||||
work, while in atom-shell we chose a different way to integrate libuv loop to
|
||||
work, while in Electron we chose a different way to integrate libuv loop to
|
||||
each platform's message loop to avoid hacking Chromium, see the
|
||||
[`node_bindings`](../../atom/common/) code for how that was done.
|
||||
|
||||
**4. Multi-context**
|
||||
__4. Multi-context__
|
||||
|
||||
If you are an experienced NW.js user, you should be familiar with the
|
||||
concept of Node context and web context, these concepts were invented because
|
||||
of how the NW.js was implemented.
|
||||
|
||||
By using the [multi-context](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)
|
||||
feature of Node, atom-shell doesn't introduce a new JavaScript context in web
|
||||
feature of Node, Electron doesn't introduce a new JavaScript context in web
|
||||
pages.
|
||||
|
|
|
|||
|
|
@ -30,17 +30,17 @@ $ sudo npm install npm -g
|
|||
## Getting the code
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/atom/atom-shell.git
|
||||
$ git clone https://github.com/atom/electron.git
|
||||
```
|
||||
|
||||
## Bootstrapping
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. Notice that we're using `ninja` to build `atom-shell` so
|
||||
build project files. Notice that we're using `ninja` to build Electron so
|
||||
there is no `Makefile` generated.
|
||||
|
||||
```bash
|
||||
$ cd atom-shell
|
||||
$ cd electron
|
||||
$ ./script/bootstrap.py -v
|
||||
```
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ versions of clang. Try using clang 3.0, default version in Ubuntu 12.04.
|
|||
If you get an error like:
|
||||
|
||||
````
|
||||
/usr/bin/ld: warning: libudev.so.0, needed by /home/suyash/projects/atom-shell/vendor/brightray/vendor/download/libchromiumcontent/Release/libchromiumcontent.so, not found (try using -rpath or -rpath-link)
|
||||
/usr/bin/ld: warning: libudev.so.0, needed by .../vendor/brightray/vendor/download/libchromiumcontent/Release/libchromiumcontent.so, not found (try using -rpath or -rpath-link)
|
||||
````
|
||||
|
||||
and you are on Ubuntu 13.04+, 64 bit system, try doing
|
||||
|
|
|
|||
|
|
@ -14,17 +14,17 @@ following python modules:
|
|||
## Getting the code
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/atom/atom-shell.git
|
||||
$ git clone https://github.com/atom/electron.git
|
||||
```
|
||||
|
||||
## Bootstrapping
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. Notice that we're using `ninja` to build `atom-shell` so
|
||||
build project files. Notice that we're using `ninja` to build Electron so
|
||||
there is no Xcode project generated.
|
||||
|
||||
```bash
|
||||
$ cd atom-shell
|
||||
$ cd electron
|
||||
$ ./script/bootstrap.py -v
|
||||
```
|
||||
|
||||
|
|
@ -42,12 +42,12 @@ You can also only build the `Debug` target:
|
|||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
After building is done, you can find `Atom.app` under `out/D`.
|
||||
After building is done, you can find `Electron.app` under `out/D`.
|
||||
|
||||
## 32bit support
|
||||
|
||||
Currently atom-shell can only be built for 64bit target on OS X, and there is no
|
||||
plan to support 32bit on OS X in future.
|
||||
Electron can only be built for 64bit target on OS X, and there is no plan to
|
||||
support 32bit OS X in future.
|
||||
|
||||
## Tests
|
||||
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ If you don't have a Windows installation at the moment,
|
|||
[modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads) has
|
||||
timebombed versions of Windows that you can use to build Electron.
|
||||
|
||||
The building of atom-shell is done entirely with command-line scripts, so you
|
||||
can use any editor you like to develop atom-shell, but it also means you can
|
||||
The building of Electron is done entirely with command-line scripts, so you
|
||||
can use any editor you like to develop Electron, but it also means you can
|
||||
not use Visual Studio for the development. Support of building with Visual
|
||||
Studio will come in the future.
|
||||
|
||||
|
|
@ -24,17 +24,17 @@ Studio will come in the future.
|
|||
## Getting the code
|
||||
|
||||
```powershell
|
||||
git clone https://github.com/atom/atom-shell.git
|
||||
git clone https://github.com/atom/electron.git
|
||||
```
|
||||
|
||||
## Bootstrapping
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. Notice that we're using `ninja` to build atom-shell so
|
||||
build project files. Notice that we're using `ninja` to build Electron so
|
||||
there is no Visual Studio project generated.
|
||||
|
||||
```powershell
|
||||
cd atom-shell
|
||||
cd electron
|
||||
python script\bootstrap.py -v
|
||||
```
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ After building is done, you can find `atom.exe` under `out\D`.
|
|||
|
||||
## 64bit support
|
||||
|
||||
Currently atom-shell can only be built for 32bit target on Windows, support for
|
||||
Currently Electron can only be built for 32bit target on Windows, support for
|
||||
64bit will come in future.
|
||||
|
||||
## Tests
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
# Build system overview
|
||||
|
||||
Atom Shell uses `gyp` for project generation, and `ninja` for building, project
|
||||
Electron uses `gyp` for project generation, and `ninja` for building, project
|
||||
configurations can be found in `.gyp` and `.gypi` files.
|
||||
|
||||
## Gyp files
|
||||
|
||||
Following `gyp` files contain the main rules of building Atom Shell:
|
||||
Following `gyp` files contain the main rules of building Electron:
|
||||
|
||||
* `atom.gyp` defines how Atom Shell itself is built.
|
||||
* `atom.gyp` defines how Electron itself is built.
|
||||
* `common.gypi` adjusts the build configurations of Node to make it build
|
||||
together with Chromium.
|
||||
* `vendor/brightray/brightray.gyp` defines how `brightray` is built, and
|
||||
|
|
@ -23,7 +23,7 @@ Chromium introduced the "component build", which builds each component as a
|
|||
separate shared library, making linking very quick but sacrificing file size
|
||||
and performance.
|
||||
|
||||
In Atom Shell we took a very similar approach: for `Debug` builds, the binary
|
||||
In Electron we took a very similar approach: for `Debug` builds, the binary
|
||||
will be linked to shared library version of Chromium's components to achieve
|
||||
fast linking time; for `Release` builds, the binary will be linked to the static
|
||||
library versions, so we can have the best possible binary size and performance.
|
||||
|
|
@ -35,7 +35,7 @@ script. By default both static libraries and shared libraries will be
|
|||
downloaded and the final size should be between 800MB and 2GB according to the
|
||||
platform.
|
||||
|
||||
If you only want to build Atom Shell quickly for testing or development, you
|
||||
If you only want to build Electron quickly for testing or development, you
|
||||
can only download the shared library versions by passing the `--dev` parameter:
|
||||
|
||||
```bash
|
||||
|
|
@ -45,20 +45,20 @@ $ ./script/build.py -c D
|
|||
|
||||
## Two-phrase project generation
|
||||
|
||||
Atom Shell links with different sets of libraries in `Release` and `Debug`
|
||||
Electron links with different sets of libraries in `Release` and `Debug`
|
||||
builds, however `gyp` doesn't support configuring different link settings for
|
||||
different configurations.
|
||||
|
||||
To work around this Atom Shell uses a `gyp` variable
|
||||
To work around this Electron uses a `gyp` variable
|
||||
`libchromiumcontent_component` to control which link settings to use, and only
|
||||
generates one target when running `gyp`.
|
||||
|
||||
## Target names
|
||||
|
||||
Unlike most projects that use `Release` and `Debug` as target names, Atom Shell
|
||||
Unlike most projects that use `Release` and `Debug` as target names, Electron
|
||||
uses `R` and `D` instead. This is because `gyp` randomly crashes if there is
|
||||
only one `Release` or `Debug` build configuration is defined, and Atom Shell has
|
||||
only one `Release` or `Debug` build configuration is defined, and Electron has
|
||||
to only generate one target for one time as stated above.
|
||||
|
||||
This only affects developers, if you are only building Atom Shell for rebranding
|
||||
This only affects developers, if you are only building Electron for rebranding
|
||||
you are not affected.
|
||||
|
|
|
|||
|
|
@ -25,4 +25,4 @@ Guide](https://github.com/styleguide/javascript), and also following rules:
|
|||
When creating a new API, we should prefer getters and setters instead of
|
||||
jQuery's one-function style, for example, `.getText()` and `.setText(text)`
|
||||
are preferred to `.text([text])`. There is a
|
||||
[discussion](https://github.com/atom/atom-shell/issues/46) of this.
|
||||
[discussion](https://github.com/atom/electron/issues/46) of this.
|
||||
|
|
|
|||
|
|
@ -8,13 +8,13 @@ forcing users to download large debugging files. The server functions like
|
|||
[Microsoft's symbol server](http://support.microsoft.com/kb/311503) so the
|
||||
documentation there can be useful.
|
||||
|
||||
Note that because released atom-shell builds are heavily optimized, debugging is
|
||||
Note that because released Electron builds are heavily optimized, debugging is
|
||||
not always easy. The debugger will not be able to show you the content of all
|
||||
variables and the execution path can seem strange because of inlining, tail
|
||||
calls, and other compiler optimizations. The only workaround is to build an
|
||||
unoptimized local build.
|
||||
|
||||
The official symbol server URL for atom-shell is
|
||||
The official symbol server URL for Electron is
|
||||
http://54.249.141.255:8086/atom-shell/symbols.
|
||||
You cannot visit this URL directly: you must add it to the symbol path of your
|
||||
debugging tool. In the examples below, a local cache directory is used to avoid
|
||||
|
|
@ -24,7 +24,7 @@ appropriate cache directory on your machine.
|
|||
## Using the symbol server in Windbg
|
||||
|
||||
The Windbg symbol path is configured with a string value delimited with asterisk
|
||||
characters. To use only the atom-shell symbol server, add the following entry to
|
||||
characters. To use only the Electron symbol server, add the following entry to
|
||||
your symbol path (__note:__ you can replace `c:\code\symbols` with any writable
|
||||
directory on your computer, if you'd prefer a different location for downloaded
|
||||
symbols):
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Overview
|
||||
|
||||
The source code of atom-shell is separated into a few parts, and we are mostly
|
||||
The source code of Electron is separated into a few parts, and we are mostly
|
||||
following Chromium on the separation conventions.
|
||||
|
||||
You may need to become familiar with [Chromium's multi-process
|
||||
|
|
@ -11,7 +11,7 @@ to understand the source code better.
|
|||
|
||||
## Structure of source code
|
||||
|
||||
* **atom** - Source code of atom-shell.
|
||||
* **atom** - Source code of Electron.
|
||||
* **app** - System entry code.
|
||||
* **browser** - The frontend including the main window, UI, and all of the
|
||||
main process things. This talks to the renderer to manage web pages.
|
||||
|
|
@ -20,7 +20,7 @@ to understand the source code better.
|
|||
* **cocoa** - Cocoa specific source code.
|
||||
* **gtk** - GTK+ specific source code.
|
||||
* **win** - Windows GUI specific source code.
|
||||
* **default_app** - The default page to show when atom-shell is started
|
||||
* **default_app** - The default page to show when Electron is started
|
||||
without providing an app.
|
||||
* **api** - The implementation of the main process APIs.
|
||||
* **lib** - Javascript part of the API implementation.
|
||||
|
|
@ -36,12 +36,12 @@ to understand the source code better.
|
|||
loop into Chromium's message loop.
|
||||
* **lib** - Common Javascript initialization code.
|
||||
* **api** - The implementation of common APIs, and foundations of
|
||||
atom-shell's built-in modules.
|
||||
Electron's built-in modules.
|
||||
* **lib** - Javascript part of the API implementation.
|
||||
* **chromium_src** - Source code that copied from Chromium.
|
||||
* **docs** - Documentations.
|
||||
* **spec** - Automatic tests.
|
||||
* **atom.gyp** - Building rules of atom-shell.
|
||||
* **atom.gyp** - Building rules of Electron.
|
||||
* **common.gypi** - Compiler specific settings and building rules for other
|
||||
components like `node` and `breakpad`.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
# Application distribution
|
||||
|
||||
To distribute your app with atom-shell, you should name the folder of your app
|
||||
as `app`, and put it under atom-shell's resources directory (on OS X it is
|
||||
`Atom.app/Contents/Resources/`, and on Linux and Windows it is `resources/`),
|
||||
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:
|
||||
|
||||
On OS X:
|
||||
|
||||
```text
|
||||
atom-shell/Atom.app/Contents/Resources/app/
|
||||
electron/Electron.app/Contents/Resources/app/
|
||||
├── package.json
|
||||
├── main.js
|
||||
└── index.html
|
||||
|
|
@ -17,14 +17,14 @@ atom-shell/Atom.app/Contents/Resources/app/
|
|||
On Windows and Linux:
|
||||
|
||||
```text
|
||||
atom-shell/resources/app
|
||||
electron/resources/app
|
||||
├── package.json
|
||||
├── main.js
|
||||
└── index.html
|
||||
```
|
||||
|
||||
Then execute `Atom.app` (or `atom` on Linux, and `atom.exe` on Windows), and
|
||||
atom-shell will start as your app. The `atom-shell` directory would then be
|
||||
Then execute `Electron.app` (or `atom` on Linux, and `atom.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.
|
||||
|
||||
## Packaging your app into a file
|
||||
|
|
@ -34,20 +34,20 @@ package your app into an [asar](https://github.com/atom/asar) archive to avoid
|
|||
exposing your app's source code to users.
|
||||
|
||||
To use an `asar` archive to replace the `app` folder, you need to rename the
|
||||
archive to `app.asar`, and put it under atom-shell's resources directory like
|
||||
bellow, and atom-shell will then try read the archive and start from it.
|
||||
archive to `app.asar`, and put it under Electron's resources directory like
|
||||
bellow, and Electron will then try read the archive and start from it.
|
||||
|
||||
On OS X:
|
||||
|
||||
```text
|
||||
atom-shell/Atom.app/Contents/Resources/
|
||||
electron/Electron.app/Contents/Resources/
|
||||
└── app.asar
|
||||
```
|
||||
|
||||
On Windows and Linux:
|
||||
|
||||
```text
|
||||
atom-shell/resources/
|
||||
electron/resources/
|
||||
└── app.asar
|
||||
```
|
||||
|
||||
|
|
@ -55,12 +55,12 @@ More details can be found in [Application packaging](application-packaging.md).
|
|||
|
||||
## Rebranding with downloaded binaries
|
||||
|
||||
After bundling your app into atom-shell, you will want to rebrand atom-shell
|
||||
After bundling your app into Electron, you will want to rebrand Electron
|
||||
before distributing it to users.
|
||||
|
||||
If you don't care about the executable name on Windows or the helper process
|
||||
name on OS X, you can simply rename the downloaded binaries, and there is also a
|
||||
grunt task that can download prebuilt atom-shell binaries for your current
|
||||
grunt task that can download prebuilt Electron binaries for your current
|
||||
platform automatically:
|
||||
[grunt-download-atom-shell](https://github.com/atom/grunt-download-atom-shell).
|
||||
|
||||
|
|
@ -75,20 +75,20 @@ name you want.
|
|||
|
||||
### OS X
|
||||
|
||||
You can rename `Atom.app` to whatever you want, and you also have to rename the
|
||||
You can rename `Electron.app` to whatever you want, and you also have to rename the
|
||||
`CFBundleDisplayName`, `CFBundleIdentifier` and `CFBundleName` fields in
|
||||
following manifest files if they have these keys:
|
||||
|
||||
* `Atom.app/Contents/Info.plist`
|
||||
* `Atom.app/Contents/Frameworks/Atom Helper.app/Contents/Info.plist`
|
||||
* `Electron.app/Contents/Info.plist`
|
||||
* `Electron.app/Contents/Frameworks/Atom Helper.app/Contents/Info.plist`
|
||||
|
||||
### Linux
|
||||
|
||||
You can rename the `atom` executable to whatever you want.
|
||||
|
||||
## Rebranding by rebuilding atom-shell from source
|
||||
## Rebranding by rebuilding Electron from source
|
||||
|
||||
The best way to rename atom-shell is to change the product name and then build
|
||||
The best way to rename Electron is to change the product name and then build
|
||||
from source. To do this you need to override the `GYP_DEFINES` environment
|
||||
variable and have a clean rebuild:
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ $ script/build.py -c Release -t myapp
|
|||
|
||||
### grunt-build-atom-shell
|
||||
|
||||
Manually checking out atom-shell's code and rebuilding could be complicated, so
|
||||
Manually checking out Electron's code and rebuilding could be complicated, so
|
||||
a Grunt task has been created that will handle this automatically:
|
||||
[grunt-build-atom-shell](https://github.com/paulcbetts/grunt-build-atom-shell).
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ source code.
|
|||
## Generating `asar` archive
|
||||
|
||||
An [asar][asar] archive is a simple tar-like format that concatenates files
|
||||
into a single file, atom-shell 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:
|
||||
|
|
@ -26,12 +26,12 @@ $ asar pack your-app app.asar
|
|||
|
||||
## Using `asar` archives
|
||||
|
||||
In atom-shell 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
|
||||
|
||||
With special patches in atom-shell, Node APIs like `fs.readFile` and `require`
|
||||
With special patches in Electron, Node APIs like `fs.readFile` and `require`
|
||||
treat `asar` archives as virtual directories, and the files in it as normal
|
||||
files in the filesystem.
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ also cause errors.
|
|||
|
||||
Most `fs` APIs can read file or get file's information from `asar` archives
|
||||
without unpacking, but for some APIs that rely on passing the real file path to
|
||||
underlying system calls, atom-shell will extract the needed file into a
|
||||
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
|
||||
work. This adds a little overhead for those APIs.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,14 +2,14 @@
|
|||
|
||||
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, atom-shell has provided the `--debug` and `--debug-brk`
|
||||
the main process, Electron has provided the `--debug` and `--debug-brk`
|
||||
switches.
|
||||
|
||||
## Command line switches
|
||||
|
||||
### `--debug=[port]`
|
||||
|
||||
When this switch is used atom-shell would listen for V8 debugger protocol
|
||||
When this switch is used Electron would listen for V8 debugger protocol
|
||||
messages on `port`, the `port` is `5858` by default.
|
||||
|
||||
### `--debug-brk=[port]`
|
||||
|
|
@ -28,18 +28,18 @@ with node-inspector, and the main process would crash if you inspect the
|
|||
$ node-inspector
|
||||
```
|
||||
|
||||
### 2. Enable debug mode for atom-shell
|
||||
### 2. Enable debug mode for Electron
|
||||
|
||||
You can either start atom-shell with a debug flag like:
|
||||
You can either start Electron with a debug flag like:
|
||||
|
||||
```bash
|
||||
$ atom-shell --debug=5858 your/app
|
||||
$ electron --debug=5858 your/app
|
||||
```
|
||||
|
||||
or, to pause your script on the first line:
|
||||
|
||||
```bash
|
||||
$ atom-shell --debug-brk=5858 your/app
|
||||
$ electron --debug-brk=5858 your/app
|
||||
```
|
||||
|
||||
### 3. Load the debugger UI
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ 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 introduces how to integrate your application into those desktop
|
||||
environments with atom-shell APIs.
|
||||
environments with Electron APIs.
|
||||
|
||||
## Recent documents (Windows & OS X)
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ To add a file to recent documents, you can use
|
|||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
app.addRecentDocument('/Users/aryastark/github/atom-shell/README.md');
|
||||
app.addRecentDocument('/Users/USERNAME/Desktop/work.type');
|
||||
```
|
||||
|
||||
And you can use [app.clearRecentDocuments](clearrecentdocuments) API to empty
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# DevTools extension
|
||||
|
||||
To make debugging more easy, atom-shell has added basic support for
|
||||
To make debugging more easy, Electron has added basic support for
|
||||
[Chrome DevTools Extension][devtools-extension].
|
||||
|
||||
For most devtools extensions, you can simply download their source codes and use
|
||||
|
|
@ -16,7 +16,7 @@ $ cd /some-directory
|
|||
$ git clone --recursive https://github.com/facebook/react-devtools.git
|
||||
```
|
||||
|
||||
Then you can load it in atom-shell by opening the devtools in arbitray window,
|
||||
Then you can load it in Electron by opening the devtools in arbitray window,
|
||||
and run this code in the console of devtools:
|
||||
|
||||
```javascript
|
||||
|
|
@ -33,20 +33,20 @@ require('remote').require('browser-window').removeDevToolsExtension('React Devel
|
|||
## Format of devtools extension
|
||||
|
||||
Ideally all devtools extension written for Chrome browser can be loaded by
|
||||
atom-shell, but they have to be in a plain directory, for those packaged `crx`
|
||||
extensions, there is no way in atom-shell to load them unless you find a way to
|
||||
Electron, but they have to be in a plain directory, for those packaged `crx`
|
||||
extensions, there is no way in Electron to load them unless you find a way to
|
||||
extract them into a directory.
|
||||
|
||||
## Background pages
|
||||
|
||||
Currently atom-shell doesn't support the background pages of chrome extensions,
|
||||
Currently Electron doesn't support the background pages of chrome extensions,
|
||||
so for some devtools extensions that rely on this feature, they may not work
|
||||
well in atom-shell
|
||||
well in Electron
|
||||
|
||||
## `chrome.*` APIs
|
||||
|
||||
Some chrome extensions use `chrome.*` APIs for some features, there is some
|
||||
effort to implement those APIs in atom-shell to make them work, but we have
|
||||
effort to implement those APIs in Electron to make them work, but we have
|
||||
only implemented few for now.
|
||||
|
||||
So if the devtools extension is using APIs other than `chrome.devtools.*`, it is
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ _online-status.html_
|
|||
There may be instances where one wants 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
|
||||
Atom-shell's inter-process communication utilities, the events can be forwarded
|
||||
Electron's inter-process communication utilities, the events can be forwarded
|
||||
to the main process and handled as needed, as shown in the following example.
|
||||
|
||||
_main.js_
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ Finally the `index.html` is the web page you want to show:
|
|||
<body>
|
||||
<h1>Hello World!</h1>
|
||||
We are using node.js <script>document.write(process.version)</script>
|
||||
and atom-shell <script>document.write(process.versions['atom-shell'])</script>.
|
||||
and atom-shell <script>document.write(process.versions['electron'])</script>.
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
|
@ -150,8 +150,8 @@ $ ./atom-shell/atom your-app/
|
|||
On OS X:
|
||||
|
||||
```bash
|
||||
$ ./Atom.app/Contents/MacOS/Atom your-app/
|
||||
$ ./Electron.app/Contents/MacOS/Atom your-app/
|
||||
```
|
||||
|
||||
`Atom.app` here is part of the atom-shell's release package, you can download
|
||||
it from [here](https://github.com/atom/atom-shell/releases).
|
||||
`Electron.app` here is part of the atom-shell's release package, you can download
|
||||
it from [here](https://github.com/atom/electron/releases).
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
# Using native Node modules
|
||||
|
||||
The native Node modules are supported by atom-shell, but since atom-shell is
|
||||
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 atom-shell's headers when building native modules.
|
||||
the location of Electron's headers when building native modules.
|
||||
|
||||
## 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 Node v0.11.x. And
|
||||
because atom-shell internally uses Node v0.11.13, it carries with the same
|
||||
because Electron internally uses Node v0.11.13, it carries with the same
|
||||
problem.
|
||||
|
||||
To solve this, you should use modules that support Node v0.11.x,
|
||||
|
|
@ -20,16 +20,16 @@ For old modules that only support Node v0.10.x, you should use the
|
|||
|
||||
### The node-gyp way
|
||||
|
||||
To build Node modules with headers of atom-shell, you need to tell `node-gyp`
|
||||
To build Node modules with headers of Electron, you need to tell `node-gyp`
|
||||
where to download headers and which version to use:
|
||||
|
||||
```bash
|
||||
$ cd /path-to-module/
|
||||
$ HOME=~/.atom-shell-gyp node-gyp rebuild --target=0.16.0 --arch=ia32 --dist-url=https://atom.io/download/atom-shell
|
||||
$ HOME=~/.electron-gyp node-gyp rebuild --target=0.16.0 --arch=ia32 --dist-url=https://atom.io/download/atom-shell
|
||||
```
|
||||
|
||||
The `HOME=~/.atom-shell-gyp` changes where to find development headers. The
|
||||
`--target=0.16.0` is version of atom-shell. The `--dist-url=...` specifies
|
||||
The `HOME=~/.electron-gyp` changes where to find development headers. The
|
||||
`--target=0.16.0` is version of Electron. The `--dist-url=...` specifies
|
||||
where to download the headers. The `--arch=ia32` says the module is built for
|
||||
32bit system.
|
||||
|
||||
|
|
@ -42,5 +42,5 @@ Node modules, except that you need to setup some environment variables:
|
|||
export npm_config_disturl=https://atom.io/download/atom-shell
|
||||
export npm_config_target=0.23.0
|
||||
export npm_config_arch=x64
|
||||
HOME=~/.atom-shell-gyp npm install module-name
|
||||
HOME=~/.electron-gyp npm install module-name
|
||||
```
|
||||
|
|
|
|||
|
|
@ -8,14 +8,14 @@ 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 atom-shell's [releases](https://github.com/atom/atom-shell/releases) page you
|
||||
can find archives of `chromedriver`, there is no difference between atom-shell's
|
||||
In Electron's [releases](https://github.com/atom/electron/releases) page you
|
||||
can find archives of `chromedriver`, there is no difference between Electron's
|
||||
distribution of `chromedriver` and upstream ones, so in order to use
|
||||
`chromedriver` together with atom-shell, you will need some special setup.
|
||||
`chromedriver` together with Electron, you will need some special setup.
|
||||
|
||||
Also notice that only minor version update releases (e.g. `vX.X.0` releases)
|
||||
include `chromedriver` archives, because `chromedriver` doesn't change as
|
||||
frequent as atom-shell itself.
|
||||
frequent as Electron itself.
|
||||
|
||||
## Setting up with WebDriverJs
|
||||
|
||||
|
|
@ -42,9 +42,9 @@ $ npm install selenium-webdriver
|
|||
|
||||
### 3. Connect to chrome driver
|
||||
|
||||
The usage of `selenium-webdriver` with atom-shell is basically the same with
|
||||
The usage of `selenium-webdriver` with Electron is basically the same with
|
||||
upstream, except that you have to manually specify how to connect chrome driver
|
||||
and where to find atom-shell's binary:
|
||||
and where to find Electron's binary:
|
||||
|
||||
```javascript
|
||||
var webdriver = require('selenium-webdriver');
|
||||
|
|
@ -53,9 +53,9 @@ var driver = new webdriver.Builder().
|
|||
// The "9515" is the port opened by chrome driver.
|
||||
usingServer('http://localhost:9515').
|
||||
withCapabilities({chromeOptions: {
|
||||
// Here is the path to your atom-shell binary.
|
||||
// Here is the path to your Electron binary.
|
||||
binary: '/Path-to-Your-App.app/Contents/MacOS/Atom'}}).
|
||||
forBrowser('atom-shell').
|
||||
forBrowser('electron').
|
||||
build();
|
||||
|
||||
driver.get('http://www.google.com');
|
||||
|
|
|
|||
Loading…
Reference in a new issue