From d2682233fd8340c2c17f32298ded3654e3a711a1 Mon Sep 17 00:00:00 2001 From: Cheng Zhao Date: Thu, 16 Apr 2015 11:31:12 +0800 Subject: [PATCH] docs: Atom Shell => Electron --- docs/api/app.md | 6 +-- docs/api/browser-window.md | 8 ++-- docs/api/chrome-command-line-switches.md | 2 +- docs/api/crash-reporter.md | 8 ++-- docs/api/file-object.md | 2 +- docs/api/frameless-window.md | 2 +- docs/api/menu.md | 2 +- docs/api/native-image.md | 2 +- docs/api/process.md | 4 +- docs/api/remote.md | 4 +- docs/api/synopsis.md | 4 +- docs/api/web-view-tag.md | 2 +- docs/development/atom-shell-vs-node-webkit.md | 28 +++++++------- docs/development/build-instructions-linux.md | 8 ++-- docs/development/build-instructions-mac.md | 12 +++--- .../development/build-instructions-windows.md | 12 +++--- docs/development/build-system-overview.md | 20 +++++----- docs/development/coding-style.md | 2 +- docs/development/setting-up-symbol-server.md | 6 +-- .../source-code-directory-structure.md | 10 ++--- docs/tutorial/application-distribution.md | 38 +++++++++---------- docs/tutorial/application-packaging.md | 8 ++-- docs/tutorial/debugging-main-process.md | 12 +++--- .../desktop-environment-integration.md | 4 +- docs/tutorial/devtools-extension.md | 14 +++---- docs/tutorial/online-offline-events.md | 2 +- docs/tutorial/quick-start.md | 8 ++-- docs/tutorial/using-native-node-modules.md | 16 ++++---- docs/tutorial/using-selenium-and-webdriver.md | 16 ++++---- 29 files changed, 132 insertions(+), 130 deletions(-) diff --git a/docs/api/app.md b/docs/api/app.md index 126dd408f801..09ffb66c0b06 100644 --- a/docs/api/app.md +++ b/docs/api/app.md @@ -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) diff --git a/docs/api/browser-window.md b/docs/api/browser-window.md index 5eff0a874c4f..16c67f4cf744 100644 --- a/docs/api/browser-window.md +++ b/docs/api/browser-window.md @@ -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 diff --git a/docs/api/chrome-command-line-switches.md b/docs/api/chrome-command-line-switches.md index e2386cc7af32..de124ac8ceba 100644 --- a/docs/api/chrome-command-line-switches.md +++ b/docs/api/chrome-command-line-switches.md @@ -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: diff --git a/docs/api/crash-reporter.md b/docs/api/crash-reporter.md index e736e7dac0d0..47e3666fa440 100644 --- a/docs/api/crash-reporter.md +++ b/docs/api/crash-reporter.md @@ -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 diff --git a/docs/api/file-object.md b/docs/api/file-object.md index 87be35ab510b..36154cdd6a1f 100644 --- a/docs/api/file-object.md +++ b/docs/api/file-object.md @@ -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. diff --git a/docs/api/frameless-window.md b/docs/api/frameless-window.md index 92abe5447a51..fe3b33388d9b 100644 --- a/docs/api/frameless-window.md +++ b/docs/api/frameless-window.md @@ -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. diff --git a/docs/api/menu.md b/docs/api/menu.md index 91a92f590521..350a0ef9e040 100644 --- a/docs/api/menu.md +++ b/docs/api/menu.md @@ -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` diff --git a/docs/api/native-image.md b/docs/api/native-image.md index de46ad1c4c4d..2ea4ed83ea4a 100644 --- a/docs/api/native-image.md +++ b/docs/api/native-image.md @@ -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 diff --git a/docs/api/process.md b/docs/api/process.md index c92ad5c82b0d..160ffc78bc8a 100644 --- a/docs/api/process.md +++ b/docs/api/process.md @@ -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. diff --git a/docs/api/remote.md b/docs/api/remote.md index 0417c657667f..6145bc181b65 100644 --- a/docs/api/remote.md +++ b/docs/api/remote.md @@ -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 diff --git a/docs/api/synopsis.md b/docs/api/synopsis.md index def3698c1e55..7dcd53363a29 100644 --- a/docs/api/synopsis.md +++ b/docs/api/synopsis.md @@ -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 diff --git a/docs/api/web-view-tag.md b/docs/api/web-view-tag.md index 241b98e14a54..e0e628feb7a3 100644 --- a/docs/api/web-view-tag.md +++ b/docs/api/web-view-tag.md @@ -1,7 +1,7 @@ # `` 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. diff --git a/docs/development/atom-shell-vs-node-webkit.md b/docs/development/atom-shell-vs-node-webkit.md index f0bc1ddac39e..6844df3556e9 100644 --- a/docs/development/atom-shell-vs-node-webkit.md +++ b/docs/development/atom-shell-vs-node-webkit.md @@ -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. diff --git a/docs/development/build-instructions-linux.md b/docs/development/build-instructions-linux.md index eba2c4b0f2dd..edaf2f79d2e2 100644 --- a/docs/development/build-instructions-linux.md +++ b/docs/development/build-instructions-linux.md @@ -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 diff --git a/docs/development/build-instructions-mac.md b/docs/development/build-instructions-mac.md index 3d35b84d3b7f..b0980a231250 100644 --- a/docs/development/build-instructions-mac.md +++ b/docs/development/build-instructions-mac.md @@ -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 diff --git a/docs/development/build-instructions-windows.md b/docs/development/build-instructions-windows.md index 48b8bc54a106..d561636aaada 100644 --- a/docs/development/build-instructions-windows.md +++ b/docs/development/build-instructions-windows.md @@ -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 diff --git a/docs/development/build-system-overview.md b/docs/development/build-system-overview.md index c2a29cf5ebcd..5aec9d74cb03 100644 --- a/docs/development/build-system-overview.md +++ b/docs/development/build-system-overview.md @@ -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. diff --git a/docs/development/coding-style.md b/docs/development/coding-style.md index 28f3c5bbe488..cc697a219dbe 100644 --- a/docs/development/coding-style.md +++ b/docs/development/coding-style.md @@ -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. diff --git a/docs/development/setting-up-symbol-server.md b/docs/development/setting-up-symbol-server.md index b69c0df02827..3149755b98de 100644 --- a/docs/development/setting-up-symbol-server.md +++ b/docs/development/setting-up-symbol-server.md @@ -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): diff --git a/docs/development/source-code-directory-structure.md b/docs/development/source-code-directory-structure.md index b529a298198c..486f553ab604 100644 --- a/docs/development/source-code-directory-structure.md +++ b/docs/development/source-code-directory-structure.md @@ -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`. diff --git a/docs/tutorial/application-distribution.md b/docs/tutorial/application-distribution.md index 8fa90a53518d..fc9bcd27a4a4 100644 --- a/docs/tutorial/application-distribution.md +++ b/docs/tutorial/application-distribution.md @@ -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). diff --git a/docs/tutorial/application-packaging.md b/docs/tutorial/application-packaging.md index f7c18b9c6a46..0741b2572447 100644 --- a/docs/tutorial/application-packaging.md +++ b/docs/tutorial/application-packaging.md @@ -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. diff --git a/docs/tutorial/debugging-main-process.md b/docs/tutorial/debugging-main-process.md index f252f22360df..857f26faa4d7 100644 --- a/docs/tutorial/debugging-main-process.md +++ b/docs/tutorial/debugging-main-process.md @@ -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 diff --git a/docs/tutorial/desktop-environment-integration.md b/docs/tutorial/desktop-environment-integration.md index 2afeb92a92ac..716f5c42c312 100644 --- a/docs/tutorial/desktop-environment-integration.md +++ b/docs/tutorial/desktop-environment-integration.md @@ -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 diff --git a/docs/tutorial/devtools-extension.md b/docs/tutorial/devtools-extension.md index 2421a4236e48..1e0a64ac3901 100644 --- a/docs/tutorial/devtools-extension.md +++ b/docs/tutorial/devtools-extension.md @@ -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 diff --git a/docs/tutorial/online-offline-events.md b/docs/tutorial/online-offline-events.md index f37fbc7e5b48..a8d669454069 100644 --- a/docs/tutorial/online-offline-events.md +++ b/docs/tutorial/online-offline-events.md @@ -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_ diff --git a/docs/tutorial/quick-start.md b/docs/tutorial/quick-start.md index bbe35988f89f..0e643d9422a7 100644 --- a/docs/tutorial/quick-start.md +++ b/docs/tutorial/quick-start.md @@ -123,7 +123,7 @@ Finally the `index.html` is the web page you want to show:

Hello World!

We are using node.js - and atom-shell . + and atom-shell . ``` @@ -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). diff --git a/docs/tutorial/using-native-node-modules.md b/docs/tutorial/using-native-node-modules.md index fa70c376820f..b03fea134e39 100644 --- a/docs/tutorial/using-native-node-modules.md +++ b/docs/tutorial/using-native-node-modules.md @@ -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 ``` diff --git a/docs/tutorial/using-selenium-and-webdriver.md b/docs/tutorial/using-selenium-and-webdriver.md index 126de19750e1..9a0f6b8116a9 100644 --- a/docs/tutorial/using-selenium-and-webdriver.md +++ b/docs/tutorial/using-selenium-and-webdriver.md @@ -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');