docs: Atom Shell => Electron

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)
 

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

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:
 

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'
+* `rept` String - e.g. 'electron-crash-service'
-* `ver` String - The version of atom-shell
+* `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

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.
 

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.

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`

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

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.

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

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

docs/api/web-view-tag.md

@@ -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.
 

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,
+So Electron works more like the Node.js runtime, and APIs are more low level,
-you can also use atom-shell for web testing purpose like
+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.

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

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
+Electron can only be built for 64bit target on OS X, and there is no plan to
-plan to support 32bit on OS X in future.
+support 32bit OS X in future.
 
 ## Tests
 

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
+The building of Electron 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
+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

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.

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.

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):

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`.
 

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
+To distribute your app with Electron, you should name the folder of your app
-as `app`, and put it under atom-shell's resources directory (on OS X it is
+as `app`, and put it under Electron's resources directory (on OS X it is
-`Atom.app/Contents/Resources/`, and on Linux and Windows it is `resources/`),
+`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
+Then execute `Electron.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
+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
+archive to `app.asar`, and put it under Electron's resources directory like
-bellow, and atom-shell will then try read the archive and start from it.
+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`
+* `Electron.app/Contents/Info.plist`
-* `Atom.app/Contents/Frameworks/Atom Helper.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).
 

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.
 

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

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

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`
+Electron, 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
+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

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_

docs/tutorial/quick-start.md

@@ -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
+`Electron.app` here is part of the atom-shell's release package, you can download
-it from [here](https://github.com/atom/atom-shell/releases).
+it from [here](https://github.com/atom/electron/releases).

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
+The `HOME=~/.electron-gyp` changes where to find development headers. The
-`--target=0.16.0` is version of atom-shell. The `--dist-url=...` specifies
+`--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
 ```

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
+In Electron's [releases](https://github.com/atom/electron/releases) page you
-can find archives of `chromedriver`, there is no difference between atom-shell's
+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');