Merge pull request #2664 from atom/jl-docs-dev
Standardize Docs: Development
This commit is contained in:
Jessica Lord
commit
28764b0f77
11 changed files with 174 additions and 165 deletions
|
|
@ -62,7 +62,7 @@ Módulos de ambos procesos:
|
|||
* [Estructura de directorio](development/source-code-directory-structure.md)
|
||||
* [Diferencias técnicas con NW.js (anteriormente conocido como node-webkit)](development/atom-shell-vs-node-webkit.md)
|
||||
* [Sistema de compilación](development/build-system-overview.md)
|
||||
* [Instrucciones de compilación (Mac)](development/build-instructions-mac.md)
|
||||
* [Instrucciones de compilación (Mac)](development/build-instructions-osx.md)
|
||||
* [Instrucciones de compilación (Windows)](development/build-instructions-windows.md)
|
||||
* [Instrucciones de compilación (Linux)](development/build-instructions-linux.md)
|
||||
* [Configurando un servidor de símbolos en el depurador](development/setting-up-symbol-server.md)
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@
|
|||
* [소스 코드 디렉터리 구조](development/source-code-directory-structure.md)
|
||||
* [NW.js(node-webkit)와 기술적으로 다른점](development/atom-shell-vs-node-webkit.md)
|
||||
* [빌드 시스템 개요](development/build-system-overview.md)
|
||||
* [빌드 설명서 (Mac)](development/build-instructions-mac.md)
|
||||
* [빌드 설명서 (Mac)](development/build-instructions-osx.md)
|
||||
* [빌드 설명서 (Windows)](development/build-instructions-windows.md)
|
||||
* [빌드 설명서 (Linux)](development/build-instructions-linux.md)
|
||||
* [디버거에서 디버그 심볼 서버 설정](development/setting-up-symbol-server.md)
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ Modules for both processes:
|
|||
* [Source code directory structure](development/source-code-directory-structure.md)
|
||||
* [Technical differences to NW.js (formerly node-webkit)](development/atom-shell-vs-node-webkit.md)
|
||||
* [Build system overview](development/build-system-overview.md)
|
||||
* [Build instructions (Mac)](development/build-instructions-mac.md)
|
||||
* [Build instructions (Mac)](development/build-instructions-osx.md)
|
||||
* [Build instructions (Windows)](development/build-instructions-windows.md)
|
||||
* [Build instructions (Linux)](development/build-instructions-linux.md)
|
||||
* [Setting up symbol server in debugger](development/setting-up-symbol-server.md)
|
||||
|
|
|
|||
|
|
@ -1,18 +1,18 @@
|
|||
# Technical differences to NW.js (formerly node-webkit)
|
||||
# Technical Differences Between Electron and NW.js (formerly node-webkit)
|
||||
|
||||
__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.
|
||||
with JavaScript and HTML and has Node integration to grant access to the low
|
||||
level system from web pages.
|
||||
|
||||
But there are also fundamental differences between the two projects that make
|
||||
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 is opened in a browser window as
|
||||
In NW.js the main entry point of an application is a web page. You specify a
|
||||
main page URL in the `package.json` and it is opened in a browser window as
|
||||
the application's main window.
|
||||
|
||||
In Electron, the entry point is a JavaScript script. Instead of
|
||||
|
|
@ -23,19 +23,18 @@ to decide when to quit the application.
|
|||
Electron works more like the Node.js runtime. Electron's APIs are lower level
|
||||
so you can use it for browser testing in place of [PhantomJS](http://phantomjs.org/).
|
||||
|
||||
__2. Build system__
|
||||
__2. Build System__
|
||||
|
||||
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. Users don't
|
||||
In order to avoid the complexity of building all of 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 of its dependencies. Users don't
|
||||
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 Electron we chose a different way to integrate libuv loop with
|
||||
each platform's message loop to avoid hacking Chromium. See the
|
||||
work, while in Electron we chose a different way to integrate the libuv loop
|
||||
with each platform's message loop to avoid hacking Chromium. See the
|
||||
[`node_bindings`](../../atom/common/) code for how that was done.
|
||||
|
||||
__4. Multi-context__
|
||||
|
|
|
|||
|
|
@ -1,15 +1,17 @@
|
|||
# Build instructions (Linux)
|
||||
# Build Instructions (Linux)
|
||||
|
||||
Follow the guidelines below for building Electron on Linux.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
* Python 2.7.x. Some distributions like CentOS still use Python 2.6.x
|
||||
so you may need to check your Python version with `python -V`.
|
||||
* Node.js v0.12.x. There are various ways to install Node. One can download
|
||||
* Node.js v0.12.x. There are various ways to install Node. You can download
|
||||
source code from [Node.js](http://nodejs.org) and compile from source.
|
||||
Doing so permits installing Node to your own home directory as a standard user.
|
||||
Or try repositories such as [NodeSource] (https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories)
|
||||
* Clang 3.4 or later
|
||||
* Development headers of GTK+ and libnotify
|
||||
Doing so permits installing Node on your own home directory as a standard user.
|
||||
Or try repositories such as [NodeSource](https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories).
|
||||
* Clang 3.4 or later.
|
||||
* Development headers of GTK+ and libnotify.
|
||||
|
||||
On Ubuntu, install the following libraries:
|
||||
|
||||
|
|
@ -33,10 +35,10 @@ managers such as pacman. Or one can compile from source code.
|
|||
|
||||
## If You Use Virtual Machines For Building
|
||||
|
||||
If you plan to build electron on a virtual machine, you will need a fixed-size
|
||||
If you plan to build Electron on a virtual machine you will need a fixed-size
|
||||
device container of at least 25 gigabytes in size.
|
||||
|
||||
## Getting the code
|
||||
## Getting the Code
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/atom/electron.git
|
||||
|
|
@ -45,8 +47,8 @@ $ git clone https://github.com/atom/electron.git
|
|||
## Bootstrapping
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. You must have Python 2.7.x for the script to succeed.
|
||||
Downloading certain files could take a long time. Notice that we are using
|
||||
the build project files. You must have Python 2.7.x for the script to succeed.
|
||||
Downloading certain files can take a long time. Notice that we are using
|
||||
`ninja` to build Electron so there is no `Makefile` generated.
|
||||
|
||||
```bash
|
||||
|
|
@ -56,7 +58,7 @@ $ ./script/bootstrap.py -v
|
|||
|
||||
### Cross compilation
|
||||
|
||||
If you want to build for `arm` target, you should also install following
|
||||
If you want to build for an `arm` target you should also install the following
|
||||
dependencies:
|
||||
|
||||
```bash
|
||||
|
|
@ -90,7 +92,7 @@ $ ./script/create-dist.py
|
|||
|
||||
This will put a working distribution with much smaller file sizes in
|
||||
the `dist` directory. After running the create-dist.py script, you
|
||||
may want to remove the 1.3+ gigabyte binary which is still in out/R.
|
||||
may want to remove the 1.3+ gigabyte binary which is still in `out/R`.
|
||||
|
||||
You can also build the `Debug` target only:
|
||||
|
||||
|
|
@ -110,12 +112,12 @@ $ ./script/clean.py
|
|||
|
||||
## Troubleshooting
|
||||
|
||||
Make sure you have installed all the build dependencies.
|
||||
Make sure you have installed all of the build dependencies.
|
||||
|
||||
### error while loading shared libraries: libtinfo.so.5
|
||||
### Error While Loading Shared Libraries: libtinfo.so.5
|
||||
|
||||
Prebulit `clang` will try to link to `libtinfo.so.5`. Depending on the host
|
||||
architecture, symlink to appropriate `libncurses`
|
||||
architecture, symlink to appropriate `libncurses`:
|
||||
|
||||
```bash
|
||||
$ sudo ln -s /usr/lib/libncurses.so.5 /usr/lib/libtinfo.so.5
|
||||
|
|
@ -123,7 +125,7 @@ $ sudo ln -s /usr/lib/libncurses.so.5 /usr/lib/libtinfo.so.5
|
|||
|
||||
## Tests
|
||||
|
||||
Test your changes confirm to the project coding style using:
|
||||
Test your changes conform to the project coding style using:
|
||||
|
||||
```bash
|
||||
$ ./script/cpplint.py
|
||||
|
|
|
|||
|
|
@ -1,17 +1,19 @@
|
|||
# Build instructions (Mac)
|
||||
# Build Instructions (OS X)
|
||||
|
||||
Follow the guidelines below for building Electron on OS X.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
* OS X >= 10.8
|
||||
* [Xcode](https://developer.apple.com/technologies/tools/) >= 5.1
|
||||
* [node.js](http://nodejs.org) (external).
|
||||
* [node.js](http://nodejs.org) (external)
|
||||
|
||||
If you are using the python downloaded by Homebrew, you also need to install
|
||||
If you are using the Python downloaded by Homebrew, you also need to install
|
||||
following python modules:
|
||||
|
||||
* pyobjc
|
||||
|
||||
## Getting the code
|
||||
## Getting the Code
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/atom/electron.git
|
||||
|
|
@ -20,7 +22,7 @@ $ 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 Electron so
|
||||
the build project files. Notice that we're using `ninja` to build Electron so
|
||||
there is no Xcode project generated.
|
||||
|
||||
```bash
|
||||
|
|
@ -44,14 +46,14 @@ $ ./script/build.py -c D
|
|||
|
||||
After building is done, you can find `Electron.app` under `out/D`.
|
||||
|
||||
## 32bit support
|
||||
## 32bit Support
|
||||
|
||||
Electron can only be built for 64bit target on OS X, and there is no plan to
|
||||
Electron can only be built for a 64bit target on OS X and there is no plan to
|
||||
support 32bit OS X in future.
|
||||
|
||||
## Tests
|
||||
|
||||
Test your changes confirm to the project coding style using:
|
||||
Test your changes conform to the project coding style using:
|
||||
|
||||
```bash
|
||||
$ ./script/cpplint.py
|
||||
|
|
@ -1,43 +1,44 @@
|
|||
# Build instructions (Windows)
|
||||
# Build Instructions (Windows)
|
||||
|
||||
Follow the guidelines below for building Electron on Windows.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
* Windows 7 / Server 2008 R2 or higher
|
||||
* Visual Studio 2013 - [download VS 2013 Community Edition for
|
||||
free](https://www.visualstudio.com/downloads/download-visual-studio-vs)
|
||||
free](https://www.visualstudio.com/downloads/download-visual-studio-vs).
|
||||
* [Python 2.7](http://www.python.org/download/releases/2.7/)
|
||||
* [Node.js](http://nodejs.org/download/)
|
||||
* [git](http://git-scm.com)
|
||||
* [Git](http://git-scm.com)
|
||||
|
||||
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.
|
||||
If you don't currently have a Windows installation, [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 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.
|
||||
Building Electron is done entirely with command-line scripts and cannot be done
|
||||
with Visual Studio. You can develop Electron with any editor but support for
|
||||
building with Visual Studio will come in the future.
|
||||
|
||||
**Note:** Even though Visual Studio is not used for building, it's still
|
||||
**required** because we need the build toolchains it provides.
|
||||
|
||||
**Note:** Visual Studio 2015 will not work. Please make sure to get MSVS **2013**.
|
||||
**Note:** Visual Studio 2015 will not work. Please make sure to get MSVS
|
||||
**2013**.
|
||||
|
||||
## Getting the code
|
||||
## Getting the Code
|
||||
|
||||
```powershell
|
||||
git clone https://github.com/atom/electron.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 Electron so
|
||||
the build project files. Notice that we're using `ninja` to build Electron so
|
||||
there is no Visual Studio project generated.
|
||||
|
||||
```powershell
|
||||
cd electron
|
||||
python script\bootstrap.py -v
|
||||
$ cd electron
|
||||
$ python script\bootstrap.py -v
|
||||
```
|
||||
|
||||
## Building
|
||||
|
|
@ -45,50 +46,51 @@ python script\bootstrap.py -v
|
|||
Build both Release and Debug targets:
|
||||
|
||||
```powershell
|
||||
python script\build.py
|
||||
$ python script\build.py
|
||||
```
|
||||
|
||||
You can also only build the Debug target:
|
||||
|
||||
```powershell
|
||||
python script\build.py -c D
|
||||
$ python script\build.py -c D
|
||||
```
|
||||
|
||||
After building is done, you can find `electron.exe` under `out\D` (debug
|
||||
target) or under `out\R` (release target).
|
||||
|
||||
## 64bit build
|
||||
## 64bit Build
|
||||
|
||||
To build for the 64bit target, you need to pass `--target_arch=x64` when running
|
||||
the bootstrap script:
|
||||
|
||||
```powershell
|
||||
python script\bootstrap.py -v --target_arch=x64
|
||||
$ python script\bootstrap.py -v --target_arch=x64
|
||||
```
|
||||
|
||||
The other building steps are exactly the same.
|
||||
|
||||
## Tests
|
||||
|
||||
Test your changes confirm to the project coding style using:
|
||||
Test your changes conform to the project coding style using:
|
||||
|
||||
```powershell
|
||||
python script\cpplint.py
|
||||
$ python script\cpplint.py
|
||||
```
|
||||
|
||||
Test functionality using:
|
||||
|
||||
```powershell
|
||||
python script\test.py
|
||||
$ python script\test.py
|
||||
```
|
||||
|
||||
Tests that include native modules (e.g. `runas`) can't be executed with the
|
||||
debug build (see #2558 for details), but they will work with the release build.
|
||||
debug build (see [#2558](https://github.com/atom/electron/issues/2558) for
|
||||
details), but they will work with the release build.
|
||||
|
||||
To run the tests with the release build use:
|
||||
|
||||
```powershell
|
||||
python script\test.py -R
|
||||
$ python script\test.py -R
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
|
@ -122,24 +124,24 @@ Traceback (most recent call last):
|
|||
subprocess.CalledProcessError: Command '['npm.cmd', 'install']' returned non-zero exit status 3
|
||||
```
|
||||
|
||||
This is caused by a bug when using Cygwin python and Win32 node together. The
|
||||
solution is to use the Win32 python to execute the bootstrap script (supposing
|
||||
you have installed python under `C:\Python27`):
|
||||
This is caused by a bug when using Cygwin Python and Win32 Node together. The
|
||||
solution is to use the Win32 Python to execute the bootstrap script (assuming
|
||||
you have installed Python under `C:\Python27`):
|
||||
|
||||
```bash
|
||||
/cygdrive/c/Python27/python.exe script/bootstrap.py
|
||||
```powershell
|
||||
$ /cygdrive/c/Python27/python.exe script/bootstrap.py
|
||||
```
|
||||
|
||||
### LNK1181: cannot open input file 'kernel32.lib'
|
||||
|
||||
Try reinstalling 32bit node.js.
|
||||
Try reinstalling 32bit Node.js.
|
||||
|
||||
### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'
|
||||
|
||||
Simply making that directory [should fix the problem](http://stackoverflow.com/a/25095327/102704):
|
||||
|
||||
```powershell
|
||||
mkdir ~\AppData\Roaming\npm
|
||||
$ mkdir ~\AppData\Roaming\npm
|
||||
```
|
||||
|
||||
### node-gyp is not recognized as an internal or external command
|
||||
|
|
|
|||
|
|
@ -1,71 +1,72 @@
|
|||
# Build system overview
|
||||
# Build System Overview
|
||||
|
||||
Electron uses `gyp` for project generation, and `ninja` for building, project
|
||||
configurations can be found in `.gyp` and `.gypi` files.
|
||||
Electron uses `gyp` for project generation and `ninja` for building. Project
|
||||
configurations can be found in the `.gyp` and `.gypi` files.
|
||||
|
||||
## Gyp files
|
||||
## Gyp Files
|
||||
|
||||
Following `gyp` files contain the main rules of building Electron:
|
||||
Following `gyp` files contain the main rules for building Electron:
|
||||
|
||||
* `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
|
||||
includes the default configurations of linking with Chromium.
|
||||
* `vendor/brightray/brightray.gyp` defines how `brightray` is built and
|
||||
includes the default configurations for linking with Chromium.
|
||||
* `vendor/brightray/brightray.gypi` includes general build configurations about
|
||||
building.
|
||||
|
||||
## Component build
|
||||
## Component Build
|
||||
|
||||
Since Chromium is quite a large project, the final linking stage would take
|
||||
quite a few minutes, making it hard for development. In order to solve this,
|
||||
Chromium introduced the "component build", which builds each component as a
|
||||
separate shared library, making linking very quick but sacrificing file size
|
||||
Since Chromium is quite a large project, the final linking stage can take
|
||||
quite a few minutes, which makes it hard for development. In order to solve
|
||||
this, 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 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
|
||||
will be linked to a 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.
|
||||
|
||||
## Minimal bootstrapping
|
||||
## Minimal Bootstrapping
|
||||
|
||||
All of Chromium's prebuilt binaries(libchromiumcontent) are downloaded when
|
||||
All of Chromium's prebuilt binaries (`libchromiumcontent`) are downloaded when
|
||||
running the bootstrap 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.
|
||||
depending on the platform.
|
||||
|
||||
By default, libchromiumcontent is downloaded from Amazon Web Services.
|
||||
If the `LIBCHROMIUMCONTENT_MIRROR` environment variable is set, bootrstrap
|
||||
By default, `libchromiumcontent` is downloaded from Amazon Web Services.
|
||||
If the `LIBCHROMIUMCONTENT_MIRROR` environment variable is set, the bootstrap
|
||||
script will download from it.
|
||||
[libchromiumcontent-qiniu-mirror](https://github.com/hokein/libchromiumcontent-qiniu-mirror)
|
||||
is a mirror for libchromiumcontent. If you have trouble in accessing AWS, you can
|
||||
switch download address to it via `export LIBCHROMIUMCONTENT_MIRROR=http://7xk3d2.dl1.z0.glb.clouddn.com/`
|
||||
[`libchromiumcontent-qiniu-mirror`](https://github.com/hokein/libchromiumcontent-qiniu-mirror)
|
||||
is a mirror for `libchromiumcontent`. If you have trouble in accessing AWS, you
|
||||
can switch the download address to it via
|
||||
`export LIBCHROMIUMCONTENT_MIRROR=http://7xk3d2.dl1.z0.glb.clouddn.com/`
|
||||
|
||||
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:
|
||||
can download just the shared library versions by passing the `--dev` parameter:
|
||||
|
||||
```bash
|
||||
$ ./script/bootstrap.py --dev
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
## Two-phrase project generation
|
||||
## Two-Phrase Project Generation
|
||||
|
||||
Electron links with different sets of libraries in `Release` and `Debug`
|
||||
builds, however `gyp` doesn't support configuring different link settings for
|
||||
builds. `gyp`, however, doesn't support configuring different link settings for
|
||||
different configurations.
|
||||
|
||||
To work around this Electron uses a `gyp` variable
|
||||
`libchromiumcontent_component` to control which link settings to use, and only
|
||||
`libchromiumcontent_component` to control which link settings to use and only
|
||||
generates one target when running `gyp`.
|
||||
|
||||
## Target names
|
||||
## Target Names
|
||||
|
||||
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 Electron has
|
||||
to only generate one target for one time as stated above.
|
||||
only one `Release` or `Debug` build configuration defined, and Electron only has
|
||||
to generate one target at a time as stated above.
|
||||
|
||||
This only affects developers, if you are only building Electron for rebranding
|
||||
This only affects developers, if you are just building Electron for rebranding
|
||||
you are not affected.
|
||||
|
|
|
|||
|
|
@ -1,35 +1,37 @@
|
|||
# Coding style
|
||||
# Coding Style
|
||||
|
||||
These are the style guidelines for coding in Electron.
|
||||
|
||||
## C++ and Python
|
||||
|
||||
For C++ and Python, we just follow Chromium's [Coding
|
||||
Style](http://www.chromium.org/developers/coding-style), there is also a
|
||||
script `script/cpplint.py` to check whether all files confirm.
|
||||
For C++ and Python, we follow Chromium's [Coding
|
||||
Style](http://www.chromium.org/developers/coding-style). There is also a
|
||||
script `script/cpplint.py` to check whether all files conform.
|
||||
|
||||
The python's version we are using now is Python 2.7.
|
||||
The Python version we are using now is Python 2.7.
|
||||
|
||||
The C++ code uses a lot of Chromium's abstractions and types, so it's
|
||||
recommended to get acquainted with them. A good place to start is
|
||||
Chromium's [Important Abstractions and Data Structures]
|
||||
(https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures)
|
||||
Chromium's [Important Abstractions and Data Structures](https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures)
|
||||
document. The document mentions some special types, scoped types (that
|
||||
automatically release their memory when going out of scope), logging mechanisms etc.
|
||||
automatically release their memory when going out of scope), logging mechanisms
|
||||
etc.
|
||||
|
||||
## CoffeeScript
|
||||
|
||||
For CoffeeScript, we follow GitHub's [Style
|
||||
Guide](https://github.com/styleguide/javascript), and also following rules:
|
||||
Guide](https://github.com/styleguide/javascript) and the following rules:
|
||||
|
||||
* Files should **NOT** end with new line, because we want to match Google's
|
||||
styles.
|
||||
* File names should be concatenated with `-` instead of `_`, e.g.
|
||||
`file-name.coffee` rather than `file_name.coffee`, because in
|
||||
[github/atom](https://github.com/github/atom) module names are usually in
|
||||
the `module-name` form, this rule only applies to `.coffee` files.
|
||||
the `module-name` form. This rule only applies to `.coffee` files.
|
||||
|
||||
## API Names
|
||||
|
||||
When creating a new API, we should prefer getters and setters instead of
|
||||
jQuery's one-function style, for example, `.getText()` and `.setText(text)`
|
||||
jQuery's one-function style. For example, `.getText()` and `.setText(text)`
|
||||
are preferred to `.text([text])`. There is a
|
||||
[discussion](https://github.com/atom/electron/issues/46) of this.
|
||||
[discussion](https://github.com/atom/electron/issues/46) on this.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Setting up symbol server in debugger
|
||||
# Setting Up Symbol Server in Debugger
|
||||
|
||||
Debug symbols allow you to have better debugging sessions. They have information
|
||||
about the functions contained in executables and dynamic libraries and provide
|
||||
|
|
@ -16,16 +16,16 @@ unoptimized local build.
|
|||
|
||||
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
|
||||
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
|
||||
repeatedly fetching the PDB from the server. Replace `c:\code\symbols` with an
|
||||
appropriate cache directory on your machine.
|
||||
|
||||
## Using the symbol server in Windbg
|
||||
## Using the Symbol Server in Windbg
|
||||
|
||||
The Windbg symbol path is configured with a string value delimited with asterisk
|
||||
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
|
||||
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):
|
||||
|
||||
|
|
|
|||
|
|
@ -1,62 +1,63 @@
|
|||
# Source code directory structure
|
||||
# Source Code Directory Structure
|
||||
|
||||
## Overview
|
||||
|
||||
The source code of Electron is separated into a few parts, and we are mostly
|
||||
The source code of Electron is separated into a few parts, mostly
|
||||
following Chromium on the separation conventions.
|
||||
|
||||
You may need to become familiar with [Chromium's multi-process
|
||||
architecture](http://dev.chromium.org/developers/design-documents/multi-process-architecture)
|
||||
to understand the source code better.
|
||||
|
||||
## Structure of source code
|
||||
## Structure of Source Code
|
||||
|
||||
* **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.
|
||||
* **lib** - Javascript part of the main process initialization code.
|
||||
* **ui** - Implementation of UI stuff for different platforms.
|
||||
* **cocoa** - Cocoa specific source code.
|
||||
* **gtk** - GTK+ specific source code.
|
||||
* **win** - Windows GUI specific source code.
|
||||
* **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.
|
||||
* **net** - Network related code.
|
||||
* **mac** - Mac specific Objective-C source code.
|
||||
* **resources** - Icons, platform-dependent files, etc.
|
||||
* **renderer** - Code that runs in renderer process.
|
||||
* **lib** - Javascript part of renderer initialization code.
|
||||
* **api** - The implementation of renderer process APIs.
|
||||
* **lib** - Javascript part of the API implementation.
|
||||
* **common** - Code that used by both the main and renderer processes,
|
||||
including some utility functions and code to integrate node's message
|
||||
loop into Chromium's message loop.
|
||||
* **lib** - Common Javascript initialization code.
|
||||
* **api** - The implementation of common APIs, and foundations of
|
||||
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 Electron.
|
||||
* **common.gypi** - Compiler specific settings and building rules for other
|
||||
```
|
||||
Electron
|
||||
├──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.
|
||||
| | ├── lib - Javascript part of the main process initialization code.
|
||||
| | ├── ui - Implementation of UI stuff for different platforms.
|
||||
| | | ├── cocoa - Cocoa specific source code.
|
||||
| | | ├── gtk - GTK+ specific source code.
|
||||
| | | └── win - Windows GUI specific source code.
|
||||
| | ├── 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.
|
||||
| | ├── net - Network related code.
|
||||
| | ├── mac - Mac specific Objective-C source code.
|
||||
| | └── resources - Icons, platform-dependent files, etc.
|
||||
| ├── renderer - Code that runs in renderer process.
|
||||
| | ├── lib - Javascript part of renderer initialization code.
|
||||
| | └── api - The implementation of renderer process APIs.
|
||||
| | └── lib - Javascript part of the API implementation.
|
||||
| └── common - Code that used by both the main and renderer processes,
|
||||
| including some utility functions and code to integrate node's message
|
||||
| loop into Chromium's message loop.
|
||||
| ├── lib - Common Javascript initialization code.
|
||||
| └── api - The implementation of common APIs, and foundations of
|
||||
| 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 Electron.
|
||||
└── common.gypi - Compiler specific settings and building rules for other
|
||||
components like `node` and `breakpad`.
|
||||
```
|
||||
|
||||
## Structure of other directories
|
||||
## Structure of Other Directories
|
||||
|
||||
* **script** - Scripts used for development purpose like building, packaging,
|
||||
testing, etc.
|
||||
* **tools** - Helper scripts used by gyp files, unlike `script`, scripts put
|
||||
here should never be invoked by users directly.
|
||||
* **vendor** - Source code of third party dependencies, we didn't use
|
||||
`third_party` as name because it would confuse with the same directory in
|
||||
`third_party` as name because it would confuse it with the same directory in
|
||||
Chromium's source code tree.
|
||||
* **node_modules** - Third party node modules used for building.
|
||||
* **out** - Temporary output directory of `ninja`.
|
||||
* **dist** - Temporary directory created by `script/create-dist.py` script
|
||||
when creating an distribution.
|
||||
* **external_binaries** - Downloaded binaries of third-party frameworks which
|
||||
do not support to be built via `gyp`.
|
||||
do not support building with `gyp`.
|
||||
|
|
|
|||
Loading…
Reference in a new issue