:zap: *프레임워크 이름이 Atom Shell에서 Electron으로 변경되었습니다* :zap:
-Electron 프레임워크는 JavaScript, HTML 그리고 CSS를 사용하여 Cross-Platform 데스크톱
-어플리케이션을 개발할 수 있도록 해주는 프레임워크입니다. 이 프레임워크는
+Electron 프레임워크는 JavaScript, HTML 그리고 CSS를 사용하여
+Cross-Platform 데스크톱 어플리케이션을 개발할 수 있도록 해주는 프레임워크입니다.
[Node.js](https://nodejs.org/)와 [Chromium](http://www.chromium.org)을 기반으로
만들어졌으며 [Atom Editor](https://github.com/atom/atom)에 사용되고 있습니다.
[@ElectronJS](https://twitter.com/electronjs)를 팔로우 하세요.
이 프로젝트는 [기여자 규약 1.2](http://contributor-covenant.org/version/1/2/0/)을
-준수합니다. 따라서 이 프로젝트의 개발에 참여하려면 이 계약을 지켜야 합니다.
-받아들일 수 없는 행위를 발견했을 경우 atom@github.com로 보고 하십시오.
+준수합니다. 따라서 이 프로젝트의 개발에 참여하려면 이 계약을 지켜야 합니다. 받아들일 수
+없는 행위를 발견했을 경우 atom@github.com로 보고 하십시오.
## 다운로드
Linux, Windows, OS X 용으로 미리 빌드된 Electron 바이너리와 디버그 심볼이 준비되어
-있습니다. [releases](https://github.com/atom/electron/releases) 페이지에서
-받아 볼 수 있습니다.
+있습니다. [releases](https://github.com/atom/electron/releases) 페이지에서 받아 볼
+수 있습니다.
-또한 [`npm`](https://docs.npmjs.com/)을 통해 미리 빌드된 Electron 바이너리를
-ì\84¤ì¹\98í\95 ì\88\98ë\8f\84 ì\9e\88ì\8aµë\8b\88ë\8b¤:
+또한 [`npm`](https://docs.npmjs.com/)을 통해 미리 빌드된 Electron 바이너리를 설치할
+수도 있습니다:
```sh
# $PATH에 `electron` 커맨드를 등록하고 전역에 설치합니다.
- Slack의 [`Atom`](http://atom-slack.herokuapp.com/) 채널
[awesome-electron](https://github.com/sindresorhus/awesome-electron) 프로젝트에
-커뮤니티가 운영중인 유용한 예제 어플리케이션과 도구, 리소스가 있으니
-한번 참고해 보시기 바랍니다.
+커뮤니티가 운영중인 유용한 예제 어플리케이션과 도구, 리소스가 있으니 한번 참고해 보시기
+바랍니다.
__참고: Electron은 Atom Shell의 새로운 이름입니다.__
-NW.js 처럼 Electron은 JavaScript와 HTML 그리고 Node 통합 환경을 제공함으로써
-웹 페이지에서 저 수준 시스템에 접근할 수 있도록 하여 웹 기반 데스크탑 어플리케이션을
+NW.js 처럼 Electron은 JavaScript와 HTML 그리고 Node 통합 환경을 제공함으로써 웹
+페이지에서 저 수준 시스템에 접근할 수 있도록 하여 웹 기반 데스크탑 어플리케이션을
작성할 수 있도록 하는 프레임워크 입니다.
하지만 Electron과 NW.js는 근본적인 개발흐름의 차이도 있습니다:
__1. 어플리케이션의 엔트리 포인트__
-NW.js에선 어플리케이션의 엔트리 포인트로 웹 페이지를 사용합니다.
-`package.json`내의 main 필드에 메인 웹 페이지(index.html) URL을 지정하면
-ì\96´í\94\8c리ì¼\80ì\9d´ì\85\98ì\9d\98 ë©\94ì\9d¸ ì\9c\88ë\8f\84ì\9a°ë¡\9c ì\97´ë¦¬ê²\8c ë\90©ë\8b\88ë\8b¤.
+NW.js에선 어플리케이션의 엔트리 포인트로 웹 페이지를 사용합니다. `package.json`내의
+main 필드에 메인 웹 페이지(index.html) URL을 지정하면 어플리케이션의 메인 윈도우로
+열리게 됩니다.
Electron에선 JavaScript를 엔트리 포인트로 사용합니다. URL을 직접 제공하는 대신 API를
사용하여 직접 브라우저 창과 HTML 파일을 로드할 수 있습니다. 또한 윈도우의 종료시기를
__3. Node 통합__
-NW.js는 웹 페이지에서 require를 사용할 수 있도록 Chromium을 패치했습니다.
-한편 Electron은 Chromium의 해킹을 방지하기 위해 libuv loop와 각 플랫폼의
-메시지 루프에 통합하는 다른 방법을 채택하였습니다.
-[`node_bindings`][node-bindings]의 코드를 보면 이 부분이 어떻게 구현됬는지를
-알 수 있습니다.
+NW.js는 웹 페이지에서 require를 사용할 수 있도록 Chromium을 패치했습니다. 한편
+Electron은 Chromium의 해킹을 방지하기 위해 libuv loop와 각 플랫폼의 메시지 루프에
+통합하는 다른 방법을 채택하였습니다. [`node_bindings`][node-bindings]의 코드를 보면
+이 부분이 어떻게 구현됬는지 알 수 있습니다.
__4. 다중 컨텍스트__
## 가상머신을 사용하여 빌드 하는 경우
-만약 Electron을 가상머신으로 빌드 할 계획이라면 해당 가상머신의 스토리지를
-ìµ\9cì\86\8c 25GB ì\9d´ì\83\81ì\9d\84 확보해 놓아야 합니다.
+만약 Electron을 가상머신으로 빌드 할 계획이라면 해당 가상머신의 스토리지를 최소 25GB
+ì\9d´ì\83\81 확보해 놓아야 합니다.
## 코드 가져오기
## 부트 스트랩
-부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고
-프로젝트 파일을 생성합니다. 스크립트가 정상적으로 작동하기 위해선
-Python 2.7.x 버전이 필요합니다. 아마 다운로드 작업이 상당히 많은 시간을
-소요할 것입니다. 참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로
-`Makefile`은 생성되지 않습니다.
+부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트
+파일을 생성합니다. 스크립트가 정상적으로 작동하기 위해선 Python 2.7.x 버전이
+필요합니다. 아마 다운로드 작업이 상당히 많은 시간을 소요할 것입니다. 참고로 Electron은
+`ninja`를 빌드 툴체인으로 사용하므로 `Makefile`은 생성되지 않습니다.
```bash
$ cd electron
$ ./script/build.py
```
-이 스크립트는 `out/R` 디렉터리에 크기가 매우 큰 Electron 실행 파일을 배치합니다.
-í\8c\8cì\9d¼ í\81¬ê¸°ë\8a\94 1.3GB를 ì´\88ê³¼í\95©ë\8b\88ë\8b¤. ì\9d´ë\9f¬í\95\9c 문ì \9cê°\80 ë°\9cì\83\9dí\95\98ë\8a\94 ì\9d´ì\9c ë\8a\94 Release í\83\80ê²\9f ë°\94ì\9d´ë\84\88리ê°\80
-디버그 심볼을 포함하기 때문입니다. 파일 크기를 줄이려면
-`create-dist.py` 스크립트를 실행하세요:
+이 스크립트는 `out/R` 디렉터리에 크기가 매우 큰 Electron 실행 파일을 배치합니다. 파일
+크기는 1.3GB를 초과합니다. 이러한 문제가 발생하는 이유는 Release 타겟 바이너리가
+디버그 심볼을 포함하기 때문입니다. 파일 크기를 줄이려면 `create-dist.py` 스크립트를
+실행하세요:
```bash
$ ./script/create-dist.py
```
-이 스크립트는 매우 작은 배포판을 `dist` 디렉터리에 생성합니다.
-create-dist.py 스크립트를 실행한 이후부턴 1.3GB를 초과하는 공간을 차지하는
-`out/R` 폴더의 바이너리는 삭제해도 됩니다.
+이 스크립트는 매우 작은 배포판을 `dist` 디렉터리에 생성합니다. create-dist.py
+스크립트를 실행한 이후부턴 1.3GB에 육박하는 공간을 차지하는 `out/R` 폴더의 바이너리는
+삭제해도 됩니다.
또는 `Debug` 타겟만 빌드 할 수 있습니다:
## libtinfo.so.5 동적 링크 라이브러리를 로드하는 도중 에러가 발생할 경우
-미리 빌드된 `clang`은 `libtinfo.so.5`로 링크를 시도합니다.
-따라서 플랫폼에 따라 적당한 `libncurses` symlink를 추가하세요:
+미리 빌드된 `clang`은 `libtinfo.so.5`로 링크를 시도합니다. 따라서 플랫폼에 따라
+적당한 `libncurses` symlink를 추가하세요:
```bash
$ sudo ln -s /usr/lib/libncurses.so.5 /usr/lib/libtinfo.so.5
## 부트 스트랩
-부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고
-í\94\84ë¡\9cì \9dí\8a¸ í\8c\8cì\9d¼ì\9d\84 ì\83\9dì\84±í\95©ë\8b\88ë\8b¤. ì°¸ê³ ë¡\9c Electronì\9d\80 ë¹\8cë\93\9c í\88´ì²´ì\9d¸ì\9c¼ë¡\9c `ninja`를 ì\82¬ì\9a©í\95\98ë¯\80ë¡\9c
-Xcode 프로젝트는 생성되지 않습니다.
+부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트
+í\8c\8cì\9d¼ì\9d\84 ì\83\9dì\84±í\95©ë\8b\88ë\8b¤. ì°¸ê³ ë¡\9c Electronì\9d\80 `ninja`를 ë¹\8cë\93\9c í\88´ì²´ì\9d¸ì\9c¼ë¡\9c ì\82¬ì\9a©í\95\98ë¯\80ë¡\9c Xcode
+프로젝트는 생성되지 않습니다.
```bash
$ cd electron
## 32비트 지원
-Electron은 현재 OS X 64비트만 지원하고 있습니다. 그리고 앞으로도 OS X 32비트는
-지원할 계획이 없습니다.
+Electron은 현재 OS X 64비트만 지원하고 있습니다. 그리고 앞으로도 OS X 32비트는 지원할
+계획이 없습니다.
## 테스트
* [Git](http://git-scm.com)
현재 사용하고 있는 PC에 Windows를 설치하지 않았다면 [modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads)에서
-사용 기한이 정해져있는 무료 가상머신 버전의 Windows를 받아 Electron을
-빌드하는 방법도 있습니다.
+사용 기한이 정해져있는 무료 가상머신 버전의 Windows를 받아 Electron을 빌드하는 방법도
+있습니다.
-Electron은 모든 빌드를 command-line 스크립트를 통해 빌드합니다. 따라서 빌드에
-Visual Studio를 사용할 수 없습니다. 하지만 여전히 Electron을 개발할 땐 아무 에디터나
-사용할 수 있습니다. 빠른 시일내에 Visual Studio를 이용한 빌드도 지원할 계획입니다.
+Electron은 모든 빌드를 command-line 스크립트를 통해 빌드합니다. 따라서 빌드에 Visual
+Studio를 사용할 수 없습니다. 하지만 여전히 Electron을 개발할 땐 어떤 에디터든 사용이
+가능합니다. 그리고 빠른 시일내에 Visual Studio를 이용한 빌드도 지원할 계획입니다.
-**참고:** Visual Studio가 직접 빌드에 사용되지 않더라도 IDE와 같이 제공된
-빌드 툴체인이 빌드에 **반드시** 사용되므로 여전히 필요합니다.
+**참고:** Visual Studio가 직접 빌드에 사용되지 않더라도 IDE와 같이 제공된 빌드
+툴체인이 빌드에 **반드시** 사용되므로 여전히 필요합니다.
-**참고:** Visual Studio 2015는 사용할 수 없습니다.
-MSVS **2013** 을 사용하고 있는지 확인해주세요.
+**참고:** Visual Studio 2015는 사용할 수 없습니다 MSVS **2013** 을 사용하고 있는지
+확인해주세요.
## 코드 가져오기
## 부트 스트랩
-부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고
-í\94\84ë¡\9cì \9dí\8a¸ í\8c\8cì\9d¼ì\9d\84 ì\83\9dì\84±í\95©ë\8b\88ë\8b¤. ì°¸ê³ ë¡\9c Electronì\9d\80 ë¹\8cë\93\9c í\88´ì²´ì\9d¸ì\9c¼ë¡\9c `ninja`를 ì\82¬ì\9a©í\95\98ë¯\80ë¡\9c
-Visual Studio 프로젝트는 생성되지 않습니다.
+부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트
+í\8c\8cì\9d¼ì\9d\84 ì\83\9dì\84±í\95©ë\8b\88ë\8b¤. ì°¸ê³ ë¡\9c Electronì\9d\80 `ninja`를 ë¹\8cë\93\9c í\88´ì²´ì\9d¸ì\9c¼ë¡\9c ì\82¬ì\9a©í\95\98ë¯\80ë¡\9c Visual
+Studio 프로젝트는 생성되지 않습니다.
```powershell
$ cd electron
## 64비트 빌드
-64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때
-`--target_arch=x64` 인자를 같이 넘겨주면 됩니다:
+64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때 `--target_arch=x64`
+인자를 같이 넘겨주면 됩니다:
```powershell
$ python script\bootstrap.py -v --target_arch=x64
$ python script\test.py
```
-테스트 실행시 `runas`와 같은 네이티브 모듈을 포함하는데 이 모듈은 디버그 빌드에서
-같이 사용할 수 없습니다. 하지만 여전히 릴리즈 빌드에선 사용할 수 있습니다.
+테스트 실행시 `runas`와 같은 네이티브 모듈을 포함하는데 이 모듈은 디버그 빌드에서 같이
+사용할 수 없습니다. 하지만 여전히 릴리즈 빌드에선 사용할 수 있습니다.
릴리즈 빌드로 테스트를 실행하려면 다음 커맨드를 사용하면 됩니다:
### Assertion failed: ((handle))->activecnt >= 0
-Cygwin에서 빌드 할 경우 `bootstrap.py` 스크립트가 다음의 에러와 함께 빌드에
-ì\8b¤í\8c¨í\95 ì\88\98 ì\9e\88ì\8aµë\8b\88ë\8b¤:
+Cygwin에서 빌드 할 경우 `bootstrap.py` 스크립트가 다음의 에러와 함께 빌드에 실패할 수
+있습니다:
```
Assertion failed: ((handle))->activecnt >= 0, file src\win\pipe.c, line 1430
subprocess.CalledProcessError: Command '['npm.cmd', 'install']' returned non-zero exit status 3
```
-이 버그는 Cygwin Python과 Win32 Node를 같이 사용할 때 발생합니다.
-부트스트랩 스크립트에서 Win32 Python을 사용함으로써 이 문제를 해결할 수 있습니다.
-`C:\Python27` 디렉터리에 Python이 설치되었다는 가정하에 다음 명령을 실행하면 됩니다:
+이 버그는 Cygwin Python과 Win32 Node를 같이 사용할 때 발생합니다. 부트스트랩
+스크립트에서 Win32 Python을 사용함으로써 이 문제를 해결할 수 있습니다. `C:\Python27`
+디렉터리에 Python이 설치되었다는 가정하에 다음 명령을 실행하면 됩니다:
```bash
$ /cygdrive/c/Python27/python.exe script/bootstrap.py
* `atom.gyp`는 Electron의 빌드 과정 자체를 정의합니다.
* `common.gypi`는 Node가 Chromium과 함께 빌드될 수 있도록 조정한 빌드 설정입니다.
-* `vendor/brightray/brightray.gyp`는 `brightray`의 빌드 과정을 정의하고
- Chromium 링킹에 대한 기본적인 설정을 포함합니다.
+* `vendor/brightray/brightray.gyp`는 `brightray`의 빌드 과정을 정의하고 Chromium
+ 링킹에 대한 기본적인 설정을 포함합니다.
* `vendor/brightray/brightray.gypi`는 빌드에 대한 일반적인 설정이 포함되어 있습니다.
## 구성요소 빌드
Chromium은 꽤나 큰 프로젝트입니다. 이러한 이유로 인해 최종 링킹 작업은 상당한 시간이
소요될 수 있습니다. 보통 이런 문제는 개발을 어렵게 만듭니다. 우리는 이 문제를 해결하기
-위해 Chromium의 "component build" 방식을 도입했습니다. 이는 각각의 컴포넌트를
-각각 따로 분리하여 공유 라이브러리로 빌드 합니다. 하지만 이 빌드 방식을 사용하면
-ë§\81í\82¹ ì\9e\91ì\97\85ì\9d\80 매ì\9a° 빨ë\9d¼ì§\80ì§\80ë§\8c ì\8b¤í\96\89 í\8c\8cì\9d¼ í\81¬ê¸°ê°\80 커ì§\80ê³ ì\84±ë\8a¥ì\9d´ ì \80í\95\98ë\90©ë\8b\88ë\8b¤.
+위해 Chromium의 "component build" 방식을 도입했습니다. 이는 각각의 컴포넌트를 각각
+따로 분리하여 공유 라이브러리로 빌드 합니다. 하지만 이 빌드 방식을 사용하면 링킹 작업은
+매우 빨라지지만 실행 파일 크기가 커지고 성능이 저하됩니다.
Electron도 이러한 방식에 상당히 비슷한 접근을 했습니다:
`Debug` 빌드 시 바이너리는 공유 라이브러리 버전의 Chromium 컴포넌트를 사용함으로써
기본적으로 공유 라이브러리와 정적 라이브러리 모두 다운로드되며 최종 전체 파일 크기는
플랫폼에 따라 800MB에서 2GB까지 차지합니다.
-기본적으로 (`libchromiumcontent`)는 Amazon Web Service를 통해 다운로드 됩니다.
-만약 `LIBCHROMIUMCONTENT_MIRROR` 환경 변수가 설정되어 있으면 부트스트랩은 해당 링크를
+기본적으로 (`libchromiumcontent`)는 Amazon Web Service를 통해 다운로드 됩니다. 만약
+`LIBCHROMIUMCONTENT_MIRROR` 환경 변수가 설정되어 있으면 부트스트랩은 해당 링크를
사용하여 바이너리를 다운로드 합니다. [libchromiumcontent-qiniu-mirror](https://github.com/hokein/libchromiumcontent-qiniu-mirror)는
libchromiumcontent의 미러입니다. 만약 AWS에 접근할 수 없다면
`export LIBCHROMIUMCONTENT_MIRROR=http://7xk3d2.dl1.z0.glb.clouddn.com/` 미러를
통해 다운로드 할 수 있습니다.
-만약 빠르게 Electron의 개발 또는 테스트만 하고 싶다면 `--dev` 플래그를 추가하여
-공유 라이브러리만 다운로드할 수 있습니다:
+만약 빠르게 Electron의 개발 또는 테스트만 하고 싶다면 `--dev` 플래그를 추가하여 공유
+라이브러리만 다운로드할 수 있습니다:
```bash
$ ./script/bootstrap.py --dev
지원하지 않습니다.
이 문제를 해결하기 위해 Electron은 링크 설정을 제어하는 `gyp` 변수
-`libchromiumcontent_component`를 사용하고 `gyp`를 실행할 때
-단 하나의 타겟만을 생성합니다.
+`libchromiumcontent_component`를 사용하고 `gyp`를 실행할 때 단 하나의 타겟만을
+생성합니다.
## 타겟 이름
많은 프로젝트에서 타겟 이름을 `Release` 와 `Debug`를 사용하는데 반해 Electron은
-`R`과 `D`를 대신 사용합니다. 이유는 가끔 알 수 없는 이유(randomly)로
-`Release` 와 `Debug` 중 하나만 빌드 설정에 정의되어 있을때 `gyp`가 크래시를 일으키는데
-이유는 앞서 말한 바와 같이 Electron은 한번에 한개의 타겟만을 생성할 수 있기 때문입니다.
+`R`과 `D`를 대신 사용합니다. 이유는 가끔 알 수 없는 이유(randomly)로 `Release` 와
+`Debug` 중 하나만 빌드 설정에 정의되어 있을때 `gyp`가 크래시를 일으키는데 이유는 앞서
+말한 바와 같이 Electron은 한번에 한개의 타겟만을 생성할 수 있기 때문입니다.
이 문제는 개발자에게만 영향을 미칩니다. 만약 단순히 Electron을 rebranding 하기 위해
빌드 하는 것이라면 이 문제에 신경 쓸 필요가 없습니다.
## C++과 Python
-C++과 Python 스크립트는 Chromium의 [코딩 스타일](http://www.chromium.org/developers/coding-style)을 따릅니다.
-파이선 스크립트 `script/cpplint.py`를 사용하여 모든 파일이 해당 코딩스타일에 맞게 코딩 되었는지 확인할 수 있습니다.
+C++과 Python 스크립트는 Chromium의
+[코딩 스타일](http://www.chromium.org/developers/coding-style)을 따릅니다. 파이선
+스크립트 `script/cpplint.py`를 사용하여 모든 파일이 해당 코딩스타일에 맞게 코딩 했는지
+확인할 수 있습니다.
Python 버전은 2.7을 사용합니다.
-C++ 코드는 많은 Chromium의 추상화와 타입을 사용합니다. 따라서 Chromium 코드에 대해 잘 알고 있어야 합니다.
-이와 관련하여 시작하기 좋은 장소로 Chromium의 [Important Abstractions and Data Structures]
-(https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures) 문서가 있습니다.
-이 문서에선 몇가지 특별한 타입과 스코프 타입(스코프 밖으로 나가면 자동으로 메모리에서 할당을 해제합니다. 스마트 포인터로 보시면 됩니다)
-그리고 로깅 메커니즘 등을 언급하고 있습니다.
+C++ 코드는 많은 Chromium의 추상화와 타입을 사용합니다. 따라서 Chromium 코드에 대해 잘
+알고 있어야 합니다. 이와 관련하여 시작하기 좋은 장소로 Chromium의
+[Important Abstractions and Data Structures](https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures)
+문서가 있습니다. 이 문서에선 몇가지 특별한 타입과 스코프 타입(스코프 밖으로 나가면
+자동으로 메모리에서 할당을 해제합니다. 스마트 포인터와 같습니다) 그리고 로깅 메커니즘
+등을 언급하고 있습니다.
## CoffeeScript
-CoffeeScript의 경우 GitHub의 [스타일 가이드](https://github.com/styleguide/javascript)를 기본으로 따릅니다.
-그리고 다음 규칙을 따릅니다:
+CoffeeScript의 경우 GitHub의
+[스타일 가이드](https://github.com/styleguide/javascript)를 기본으로 따릅니다.
+그리고 추가로 다음 규칙을 따릅니다:
* Google의 코딩 스타일에도 맞추기 위해 파일의 끝에는 **절대** 개행을 삽입해선 안됩니다.
-* 파일 이름의 공백은 `_`대신에 `-`을 사용하여야 합니다. 예를 들어 `file_name.coffee`를
-`file-name.coffee`로 고쳐야합니다. 왜냐하면 [github/atom](https://github.com/github/atom) 에서 사용되는 모듈의 이름은
-보통 `module-name`형식이기 때문입니다. 이 규칙은 '.coffee' 파일에만 적용됩니다.
+* 파일 이름의 공백은 `_`대신에 `-`을 사용하여야 합니다. 예를 들어
+`file_name.coffee`를 `file-name.coffee`로 고쳐야합니다. 왜냐하면
+[github/atom](https://github.com/github/atom)에서 사용되는 모듈의 이름은 보통
+`module-name` 형식이기 때문입니다. 이 규칙은 '.coffee' 파일에만 적용됩니다.
## API 이름
-새로운 API를 만들 땐 getter, setter스타일 대신 jQuery의 one-function스타일을 사용해야 합니다. 예를 들어
-`.getText()`와 `.setText(text)`대신에 `.text([text])`형식으로 설계하면 됩니다.
-포럼에 이 문제에 대한 [논의](https://github.com/atom/electron/issues/46)가 있습니다.
+새로운 API를 만들 땐 getter, setter스타일 대신 jQuery의 one-function 스타일을
+사용해야 합니다. 예를 들어 `.getText()`와 `.setText(text)`대신에 `.text([text])`
+형식으로 설계하면 됩니다. 포럼에 이 문제에 대한 [논의](https://github.com/atom/electron/issues/46)가
+진행되고 있습니다.
# 디버거에서 디버그 심볼 서버 설정
-디버그 심볼은 디버깅 세션을 더 좋게 개선해 줍니다. 디버그 심볼은 실행 파일과 동적 링크 라이브러리에서 메서드에 대한 정보를 담고 있으며 명료한 함수 호출 스텍 정보를 제공합니다.
-심볼 서버는 유저가 크기가 큰 디버깅용 파일을 필수적으로 다운로드 받지 않고도 디버거가 알맞은 심볼, 바이너리 그리고 소스를 자동적으로 로드할 수 있도록 해줍니다.
-서버 사용법은 [Microsoft의 심볼 서버](http://support.microsoft.com/kb/311503)와 비슷합니다. 이 문서를 참조하세요.
-
-참고로 릴리즈된 Electron 빌드는 자체적으로 많은 최적화가 되어 있는 관계로 경우에 따라 디버깅이 쉽지 않을 수 있습니다.
-Inlining, tail call 등의 컴파일러 최적화에 의해 디버거가 모든 변수의 컨텐츠를 보여줄 수 없는 경우도 있고 실행 경로가 이상하게 보여질 수 있습니다.
-유일한 해결 방법은 최적화되지 않은 로컬 빌드를 하는 것입니다.
-
-공식적인 Electron의 심볼 서버의 URL은 http://54.249.141.255:8086/atom-shell/symbols 입니다.
-일단 이 URL에 직접적으로 접근할 수는 없습니다: 디버깅 툴에 심볼의 경로를 추가해야합니다.
-아래의 예제를 참고하면 로컬 캐시 디렉터리는 서버로부터 중복되지 않게 PDB를 가져오는데 사용됩니다.
+디버그 심볼은 디버깅 세션을 더 좋게 개선해 줍니다. 디버그 심볼은 실행 파일과 동적 링크
+라이브러리에서 메서드에 대한 정보를 담고 있으며 명료한 함수 호출 스텍 정보를 제공합니다.
+심볼 서버는 유저가 크기가 큰 디버깅용 파일을 필수적으로 다운로드 받지 않고도 디버거가
+알맞은 심볼, 바이너리 그리고 소스를 자동적으로 로드할 수 있도록 해줍니다. 서버 사용법은
+[Microsoft의 심볼 서버](http://support.microsoft.com/kb/311503)와 비슷합니다.
+사용법을 알아보려면 이 문서를 참조하세요.
+
+참고로 릴리즈된 Electron 빌드는 자체적으로 많은 최적화가 되어 있는 관계로 경우에 따라
+디버깅이 쉽지 않을 수 있습니다. Inlining, tail call 등 컴파일러 최적화에 의해 디버거가
+모든 변수의 컨텐츠를 보여줄 수 없는 경우도 있고 실행 경로가 이상하게 보여지는 경우도
+있습니다. 유일한 해결 방법은 최적화되지 않은 로컬 빌드를 하는 것입니다.
+
+공식적인 Electron의 심볼 서버의 URL은
+http://54.249.141.255:8086/atom-shell/symbols 입니다. 일단 이 URL에 직접적으로
+접근할 수는 없습니다: 디버깅 툴에 심볼의 경로를 추가해야합니다. 아래의 예제를 참고하면
+로컬 캐시 디렉터리는 서버로부터 중복되지 않게 PDB를 가져오는데 사용됩니다.
`c:\code\symbols` 캐시 디렉터리를 사용중인 OS에 맞춰 적당한 경로로 변경하세요.
## Windbg에서 심볼 서버 사용하기
-Windbg 심볼 경로는 구분자와 *(별) 문자로 설정되어 있습니다.
-Electron 심볼 서버만을 사용하려면 심볼 경로의 엔트리를 추가해야 합니다 (__참고:__ `c:\code\symbols` 디렉터리 경로를 PC가 원하는 경로로 수정할 수 있습니다):
+Windbg 심볼 경로는 구분자와 `*` 문자로 설정되어 있습니다. Electron 심볼 서버만
+사용하려면 심볼 경로의 엔트리를 추가해야 합니다. (__참고:__ `c:\code\symbols`
+디렉터리 경로를 PC가 원하는 경로로 수정할 수 있습니다):
```
SRV*c:\code\symbols\*http://54.249.141.255:8086/atom-shell/symbols
```
-Windbg 메뉴 또는 `.sympath` 커맨드를 이용하여 환경에 `_NT_SYMBOL_PATH` 문자열을 설정합니다.
-만약 Microsoft의 심볼서버로 부터 심볼을 받아오려면 다음과 같이 리스팅을 먼저 해야합니다:
+Windbg 메뉴 또는 `.sympath` 커맨드를 이용하여 환경에 `_NT_SYMBOL_PATH` 문자열을
+설정합니다. 만약 Microsoft의 심볼서버로 부터 심볼을 받아오려면 다음과 같이 리스팅을
+먼저 해야합니다:
```
SRV*c:\code\symbols\*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols\*http://54.249.141.255:8086/atom-shell/symbols
## 문제 해결: Symbols will not load
-Windbg에서 다음의 커맨드를 입력하여 왜 심볼이 로드되지 않았는지에 대한 오류 내역을 출력합니다:
+Windbg에서 다음의 커맨드를 입력하여 왜 심볼이 로드되지 않았는지에 대한 오류 내역을
+출력합니다:
```
> !sym noisy
# 소스 코드 디렉터리 구조
-Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 그리고 Chromium의 분리 규칙(separation conventions)을 주로 따르고 있습니다.
+Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 그리고 Chromium의 분리
+규칙(separation conventions)을 주로 따르고 있습니다.
-이미 [Chromium의 멀티 프로세스 아키텍쳐](http://dev.chromium.org/developers/design-documents/multi-process-architecture)에 익숙해져 있다면 소스 코드를 이해하기 쉬울 것입니다.
+이미 [Chromium의 멀티 프로세스 아키텍쳐](http://dev.chromium.org/developers/design-documents/multi-process-architecture)에
+익숙해져 있다면 소스 코드를 이해하기 쉬울 것입니다.
## 소스 코드 구조
Electron
├──atom - Electron의 소스코드.
| ├── app - 시스템 엔트리 코드.
-| ├── browser - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것들.
-| | | 랜더러와 웹 페이지 관리 관련 코드.
+| ├── browser - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것과
+| | 랜더러와 웹 페이지 관리 관련 코드.
| | ├── lib - 메인 프로세스 초기화 코드의 자바스크립트 파트.
| | ├── ui - 크로스 플랫폼에 대응하는 UI 구현.
| | | ├── cocoa - 코코아 특정 소스 코드.
| | ├── lib - 랜더러 프로세스 초기화 코드의 자바스크립트 파트.
| | └── api - 랜더러 프로세스 API들의 구현.
| | └── lib - API 구현의 자바스크립트 파트.
-| └── common - 메인 프로세스와 랜더러 프로세스에서 공유하는 코드.
-| | 유틸리티 함수와 node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드도 포함.
+| └── common - 메인 프로세스와 랜더러 프로세스에서 공유하는 코드. 유틸리티 함수와
+| node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드도 포함.
| ├── lib - 공통 자바스크립트 초기화 코드.
| └── api - 공통 API들의 구현, Electron의 빌트인 모듈 기초 코드들.
| └── lib - API 구현의 자바스크립트 파트.
├── docs - 참조 문서.
├── spec - 자동화된 테스트.
├── atom.gyp - Electron의 빌드 규칙.
-└── common.gypi - 컴파일러 설정 및 `node` 와 `breakpad` 등의 구성요소를 위한 빌드 규칙.
+└── common.gypi - 컴파일러 설정 및 `node` 와 `breakpad` 등의 구성요소를 위한 빌드
+ 규칙.
```
## 그외 디렉터리 구조
* **script** - 개발목적으로 사용되는 빌드, 패키징, 테스트, 기타등을 실행하는 스크립트.
-* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트 `script`와는 다르게 유저로부터 직접 실행되지 않는 스크립트들을 이곳에 넣습니다.
-* **vendor** - 소스코드의 서드파티 종속성 코드 소스 코드 디렉터리가 겹쳐 혼란을 일으킬 수 있기 때문에
- 우리는 `third_party`와 같은 Chromium 소스 코드 디렉터리에서 사용된 폴더 이름을 사용하지 않았습니다.
+* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트 `script`와는 다르게 유저로부터 직접
+ 실행되지 않는 스크립트들을 이곳에 넣습니다.
+* **vendor** - 소스코드의 서드파티 종속성 코드 소스 코드 디렉터리가 겹쳐 혼란을 일으킬
+ 수 있기 때문에 `third_party`와 같은 Chromium 소스 코드 디렉터리에서 사용된 폴더
+ 이름은 사용하지 않았습니다.
* **node_modules** - 빌드에 사용되는 node 서드파티 모듈.
* **out** - `ninja`의 임시 출력 디렉터리.
-* **dist** - 배포용 바이너리를 빌드할 때 사용하는 `script/create-dist.py` 스크립트로부터 만들어지는 임시 디렉터리.
-* **external_binaries** - `gyp` 빌드를 지원하지 않아 따로 다운로드된 서드파티 프레임워크 바이너리들.
+* **dist** - 배포용 바이너리를 빌드할 때 사용하는 `script/create-dist.py`
+ 스크립트로부터 만들어지는 임시 디렉터리.
+* **external_binaries** - `gyp` 빌드를 지원하지 않아 따로 다운로드된 서드파티
+ 프레임워크 바이너리들.
- `h1` 제목은 페이지당 한 개만 사용할 수 있습니다.
- 코드 블럭에서 터미널 언어 선택시 `cmd` 대신 `bash`를 사용합니다.
(syntax highlighter를 사용하기 위해서)
-- 문서의 `h1` 제목은 반드시 현재 객체 이름과 같게 해야 합니다.
- (예시: `browser-window` → `BrowserWindow`)
+- 문서의 `h1` 제목은 반드시 현재 객체 이름과 같게 해야 합니다. (`browser-window` →
+ `BrowserWindow`)
- 하이픈(-)으로 구분되었건 다르게 구분되었건 예시와 같이 작성합니다.
-- 헤더 밑에 헤더를 바로 사용하지 않습니다. 한 줄이라도 좋으니 헤더와 헤더 사이에
- ì\84¤ëª\85ì\9d\84 ì¶\94ê°\80í\95©ë\8b\88ë\8b¤.
+- 헤더 밑에 헤더를 바로 사용하지 않습니다. 한 줄이라도 좋으니 헤더와 헤더 사이에 설명을
+ 추가합니다.
- 메서드 헤더는 `code backtick` 으로 표시합니다.
- 이벤트 헤더는 한 '따옴표'로 표시합니다.
-- 리스트를 2 단계 이상 중첩하지 않습니다. (안타깝게도 markdown 랜더러가 이를
- ì§\80ì\9b\90í\95\98ì§\80 ì\95\8aì\8aµë\8b\88ë\8b¤)
+- 리스트를 2 단계 이상 중첩하지 않습니다. (안타깝게도 markdown 랜더러가 이를 지원하지
+ 않습니다)
- 섹션에 대한 제목을 추가합니다. Events, Class 메서드 그리고 인스턴스 메서드 등
- 어떤 '것'의 사용 결과를 설명할 때 '될 것입니다' 형식을 사용하여 설명합니다.
- 이벤트와 메서드를 표기할 땐 `h3` 헤더를 사용합니다.
아직 번역되지 않은 언어를 추가하려면 (일부분 포함):
- 언어의 약어(예: en-US, ja-JP, ko-KR)로 서브 디렉터리를 만듭니다.
-- 서브 디렉터리에 `docs` 디렉터리를 복사합니다. 파일 이름과 디렉터리 구조는
- 모두 유지합니다.
+- 서브 디렉터리에 `docs` 디렉터리를 복사합니다. 파일 이름과 디렉터리 구조는 모두
+ 유지합니다.
- 문서를 번역합니다.
- 언어 디렉터리 내의 `README.md`에 번역한 문서의 링크를 추가합니다.
- 메인(upstream) Electron의 [README](https://github.com/atom/electron#documentation-translations)에
메서드 이름은 인수가 무엇을 받는지에 따라 결정됩니다. 선택적 인수는 브라켓([, ])으로
묶어 이 인수가 다른 인수뒤에서 선택적으로 사용될 수 있다는 것을 표시합니다.
-메서드 이름 하단에선 각 인수에 대해 자세한 설명을 합니다.
-인수의 타입은 일반적인 타입 중 하나를 받거나:
+메서드 이름 하단에선 각 인수에 대해 자세한 설명을 합니다. 인수의 타입은:
[`String`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String),
[`Number`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number),
[`Object`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object),
[`Array`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)
-와 같은 일반적으로 쓰이는 타입 중 하나를 받거나 Electron의
-[`webContent`](api/web-content.md)같은 커스텀 타입을 받습니다.
+와 같은 일반적으로 쓰이는 타입 중 하나를 받거나 Electron의 [`webContent`](api/web-content.md)
+같은 커스텀 타입을 받습니다.
### Events
Electron 어플리케이션을 배포하는 방법은 간단합니다.
-먼저 폴더 이름을 `app`로 지정한 후 Electron 리소스 디렉터리에 폴더를 통째로 집어넣기만 하면 됩니다.
-리소스 디렉터리는 OS X: `Electron.app/Contents/Resources/` Windows와 Linux: `resources/` 입니다.
-
-예제:
+먼저 폴더 이름을 `app`로 지정한 후 Electron 리소스 디렉터리에 폴더를 통째로 집어넣기만
+하면 됩니다. 리소스 디렉터리는 OS X의 경우: `Electron.app/Contents/Resources/`
+Windows와 Linux의 경우: `resources/` 입니다.
OS X의 경우:
└── index.html
```
-Windows 와 Linux의 경우:
+Windows와 Linux의 경우:
```text
electron/resources/app
└── index.html
```
-그리고 `Electron.app`을 실행하면(Linux에선 `electron` Windows에선 `electron.exe`입니다) Electron 앱이 실행시킵니다.
-최종 사용자에겐 이 `electron` 폴더(Electron.app)를 배포하면 됩니다.
+그리고 `Electron.app`을 실행하면(Linux에선 `electron` Windows에선 `electron.exe`
+입니다) Electron 앱이 실행됩니다. 최종 사용자에겐 이 `electron` 폴더(Electron.app)를
+배포하면 됩니다.
## asar로 앱 패키징 하기
-소스파일 전체를 복사해서 배포하는 것과는 별개로 [asar](https://github.com/atom/asar) 아카이브를 통해
-어플리케이션의 소스코드가 사용자에게 노출되는 것을 방지할 수 있습니다.
+소스파일 전체를 복사해서 배포하는 것과는 별개로 [asar](https://github.com/atom/asar)
+ì\95\84ì¹´ì\9d´ë¸\8c를 í\86µí\95´ ì\96´í\94\8c리ì¼\80ì\9d´ì\85\98ì\9d\98 ì\86\8cì\8a¤ì½\94ë\93\9cê°\80 ì\82¬ì\9a©ì\9e\90ì\97\90ê²\8c ë\85¸ì¶\9cë\90\98ë\8a\94 ê²\83ì\9d\84 ë°©ì§\80í\95 ì\88\98 ì\9e\88ì\8aµë\8b\88ë\8b¤.
-`asar` 아카이브를 사용할 땐 단순히 `app` 폴더 대신에 어플리케이션을 패키징한 `app.asar` 파일로 대체하면됩니다.
-Electron은 자동으로 `app`폴더 대신 asar 아카이브를 기반으로 어플리케이션을 실행합니다.
+`asar` 아카이브를 사용할 땐 단순히 `app` 폴더 대신에 어플리케이션을 패키징한
+`app.asar` 파일로 대체하면됩니다. Electron은 자동으로 `app`폴더 대신 asar 아카이브를
+기반으로 어플리케이션을 실행합니다.
OS X의 경우:
### Windows
`electron.exe`을 원하는 이름으로 변경할 수 있습니다.
-그리고 [rcedit](https://github.com/atom/rcedit) 또는 [ResEdit](http://www.resedit.net)를 사용하여 아이콘을 변경할 수 있습니다.
+그리고 [rcedit](https://github.com/atom/rcedit) 또는
+[ResEdit](http://www.resedit.net)를 사용하여 아이콘을 변경할 수 있습니다.
### OS X
-`Electron.app`을 원하는 이름으로 변경할 수 있습니다. 그리고 다음 표시된 어플리케이션 내부 파일에서
-`CFBundleDisplayName`, `CFBundleIdentifier` and `CFBundleName` 필드를 원하는 이름으로 변경해야합니다:
+`Electron.app`을 원하는 이름으로 변경할 수 있습니다. 그리고 다음 표시된 어플리케이션
+내부 파일에서 `CFBundleDisplayName`, `CFBundleIdentifier` 그리고 `CFBundleName`
+필드를 원하는 이름으로 변경해야 합니다:
* `Electron.app/Contents/Info.plist`
* `Electron.app/Contents/Frameworks/Electron Helper.app/Contents/Info.plist`
-또한 helper 앱이 프로세스 모니터에 `Electron Helper`로 나오지 않도록 이름을 변경할 수 있습니다.
-하지만 반드시 내부 및 모든 helper 앱의 이름을 변경해야 합니다.
+또한 helper 앱이 프로세스 모니터에 `Electron Helper`로 나오지 않도록 이름을
+변경할 수 있습니다. 하지만 반드시 내부 및 모든 helper 앱의 이름을 변경해야 합니다.
-어플리케이션 아이콘은 `Electron.app/Contents/Resources/atom.icns`을 원하는 아이콘으로 변경하면 됩니다.
+어플리케이션 아이콘은 `Electron.app/Contents/Resources/atom.icns`을 원하는
+아이콘으로 변경하면 됩니다.
-ì\9b\90í\95\98ë\8a\94 ì\9d´ë¦\84ì\9c¼ë¡\9c ë°\94ê¾¼ ì\96´í\94\8c리ì¼\80ì\9d´ì\85\98 ì\98\88ì \9c:
+ì\96´í\94\8c리ì¼\80ì\9d´ì\85\98 ì\9d´ë¦\84ì\9d\84 ì\9b\90í\95\98ë\8a\94 ì\9d´ë¦\84ì\9c¼ë¡\9c ë³\80ê²½í\95\9c ì\98\88ì\8b\9c:
```
MyApp.app/Contents
### Linux
-실행파일 `electron`의 이름을 원하는 대로 바꿀 수 있습니다.
-리눅스 어플리케이션의 아이콘은 [.desktop](https://developer.gnome.org/integration-guide/stable/desktop-files.html.en) 파일을 사용하여 지정할 수 있습니다.
+실행파일 `electron`의 이름을 원하는 대로 바꿀 수 있습니다. 리눅스 어플리케이션의
+아이콘은 [.desktop](https://developer.gnome.org/integration-guide/stable/desktop-files.html.en)
+파일을 사용하여 지정할 수 있습니다.
-### 역주-자동화
+### 역주-자동화
-어플리케이션 배포시 Electron의 리소스를 일일이 수정하는 것은 매우 귀찮고 복잡합니다.
-하지만 이 작업을 자동화 시킬 수 있는 몇가지 방법이 있습니다:
+어플리케이션 배포시 Electron의 리소스를 일일이 수정하는 것은 매우 반복적이고 복잡합니다.
+하지만 이 작업을 자동화 시킬 수 있는 몇가지 방법이 있습니다:
* [electron-builder](https://github.com/loopline-systems/electron-builder)
* [electron-packager](https://github.com/maxogden/electron-packager)
### grunt-build-atom-shell
-Electron의 소스코드를 수정하고 다시 빌드하는 작업은 상당히 복잡합니다.
-일일이 소스코드를 수정하는 대신 [grunt-build-atom-shell](https://github.com/paulcbetts/grunt-build-atom-shell)을 사용하여 빌드를 자동화 시킬 수 있습니다.
+Electron의 소스코드를 수정하고 다시 빌드하는 작업은 상당히 복잡합니다. 일일이
+소스코드를 수정하는 대신 [grunt-build-atom-shell](https://github.com/paulcbetts/grunt-build-atom-shell)을
+사용하여 빌드를 자동화 시킬 수 있습니다.
-이 툴을 사용하면 자동으로 `.gyp`파일을 수정하고 다시 빌드합니다. 그리고 어플리케이션의 네이티브 Node 모듈 또한 새로운 실행파일 이름으로 매치 시킵니다.
+이 툴을 사용하면 자동으로 `.gyp`파일을 수정하고 다시 빌드합니다. 그리고 어플리케이션의
+네이티브 Node 모듈 또한 새로운 실행파일 이름으로 일치시킵니다.
# 어플리케이션 패키징
-Windows에서 일어나는 긴 경로 이름에 대한 [issues](https://github.com/joyent/node/issues/6960)를 완화하고 `require` 속도를 약간 빠르게 하며
-어플리케이션의 리소스와 소스코드를 좋지 않은 사용자로부터 보호하기 위해 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
+Windows에서 일어나는 긴 경로 이름에 대한 [issues](https://github.com/joyent/node/issues/6960)를
+완화하고 `require` 속도를 약간 빠르게 하며 어플리케이션의 리소스와 소스코드를 좋지 않은
+사용자로부터 보호하기 위해 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
## `asar` 아카이브 생성
## `asar` 아카이브 사용하기
-Electron은 Node.js로 부터 제공된 Node API와 Chromium으로부터 제공된 Web API 두 가지 API를 가지고 있습니다.
-따라서 `asar` 아카이브는 두 API 모두 사용할 수 있도록 지원합니다.
+Electron은 Node.js로 부터 제공된 Node API와 Chromium으로부터 제공된 Web API 두 가지
+API를 가지고 있습니다. 따라서 `asar` 아카이브는 두 API 모두 사용할 수 있도록
+지원합니다.
### Node API
-Electron에선 `fs.readFile`과 `require` 같은 Node API들을 지원하기 위해 `asar` 아카이브가 가상의 디렉터리 구조를 가지도록
-패치했습니다. 그래서 아카이브 내부 리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다.
+Electron에선 `fs.readFile`과 `require` 같은 Node API들을 지원하기 위해 `asar`
+아카이브가 가상의 디렉터리 구조를 가지도록 패치했습니다. 그래서 아카이브 내부
+리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다.
예를 들어 `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면:
### `asar` 아카이브를 일반 파일로 취급하기
-`asar` 아카이브의 체크섬(checksum)을 검사하는 작업등을 하기 위해선 `asar` 아카이브를 파일 그대로 읽어야 합니다.
-이러한 작업을 하기 위해 `original-fs` 빌트인 모듈을 `fs` 모듈 대신에 사용할 수 있습니다.
-이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를 읽어들입니다:
+`asar` 아카이브의 체크섬(checksum)을 검사하는 작업등을 하기 위해선 `asar` 아카이브를
+파일 그대로 읽어야 합니다. 이러한 작업을 하기 위해 `original-fs` 빌트인 모듈을 `fs`
+모듈 대신에 사용할 수 있습니다. 이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를
+읽어들입니다:
```javascript
var originalFs = require('original-fs');
## Node API의 한계
-`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만 여전히 저수준(low-level nature) Node API 때문에 한계가 있습니다.
+`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만 여전히
+저수준(low-level nature) Node API 때문에 한계가 있습니다.
### 아카이브는 읽기 전용입니다
-아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만 `asar` 아카이브에선 작동하지 않습니다.
+아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만 `asar`
+아카이브에선 작동하지 않습니다.
### 아카이브 안의 디렉터리를 작업 경로로 설정하면 안됩니다
-`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만 그것은 실제 파일시스템의 디렉터리가 아닌 가상의 디렉터리입니다.
-그런 이유로 몇몇 API에서 지원하는 `cwd` 옵션을 `asar` 아카이브 안의 디렉터리 경로로 지정하면 나중에 문제가 발생할 수 있습니다.
+`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만 그것은 실제 파일시스템의
+디렉터리가 아닌 가상의 디렉터리입니다. 그런 이유로 몇몇 API에서 지원하는 `cwd` 옵션을
+`asar` 아카이브 안의 디렉터리 경로로 지정하면 나중에 문제가 발생할 수 있습니다.
### 특정 API로 인한 예외적인 아카이브 압축 해제
-많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를 가져올 수 있으나
-몇몇 API는 시스템의 실제 파일의 경로를 기반으로 작동하므로 Electron은 API가 원할하게 작동할 수 있도록
-임시 경로에 해당되는 파일의 압축을 해제합니다. 이 작업은 약간의 오버헤드를 불러 일으킬 수 있습니다.
+많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를
+가져올 수 있으나 몇몇 API는 시스템의 실제 파일의 경로를 기반으로 작동하므로 Electron은
+API가 원할하게 작동할 수 있도록 임시 경로에 해당되는 파일의 압축을 해제합니다. 이 작업은
+약간의 오버헤드를 불러 일으킬 수 있습니다.
위 예외에 해당하는 API 메서드는 다음과 같습니다:
### `fs.stat`의 잘못된 스테이터스 정보
-`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 예측된 디렉터리 파일 정보를 가집니다.
-왜냐하면 아카이브의 디렉터리 경로는 실제 파일시스템에 존재하지 않기 때문입니다.
-그러한 이유로 파일 크기와 파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다.
+`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로
+할 경우 예측된 디렉터리 파일 정보를 가집니다. 왜냐하면 아카이브의 디렉터리 경로는 실제
+파일 시스템에 존재하지 않기 때문입니다. 그러한 이유로 파일 크기와
+파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다.
## `asar` 아카이브에 미리 압축 해제된 파일 추가하기
전술한 바와 같이 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다.
-이 방법은 성능문제가 발생할 수 있습니다. 그리고 설계상 백신 소프트웨어에서 잘못 진단하여 바이러스로 판단 할 수도 있습니다.
+이 방법은 성능문제가 발생할 수 있습니다. 그리고 설계상 백신 소프트웨어에서 잘못 진단하여
+바이러스로 진단 할 수도 있습니다.
-ì\9d´ 문ì \9c를 í\95´ê²°í\95\98ë ¤ë©´ `--unpack` ì\98µì\85\98ì\9d\84 í\99\9cì\9a©í\95\98ì\97¬ 파일을 압축이 풀려진 상태로 유지해야 합니다.
-다음의 예제는 node 네이티브 모듈의 공유 라이브러리를 unpack 상태로 유지합니다:
+ì\9d´ 문ì \9c를 í\95´ê²°í\95\98ë ¤ë©´ `--unpack` ì\98µì\85\98ì\9d\84 í\86µí\95´ 파일을 압축이 풀려진 상태로 유지해야 합니다.
+다음의 예제는 node 네이티브 모듈의 공유 라이브러리를 압축이 풀려진 상태로 유지합니다:
```bash
$ asar pack app app.asar --unpack *.node
```
-커맨드를 실행한 후 같은 디렉터리에 `app.asar` 파일 외에 `app.asar.unpacked` 폴더가 같이 생성됩니다.
-이 폴더안에 unpack 옵션에서 설정한 파일들이 압축이 풀린 상태로 포함되어 있습니다.
-사용자에게 어플리케이션을 배포할 때 반드시 해당 폴더도 같이 배포해야 합니다.
+커맨드를 실행한 후 같은 디렉터리에 `app.asar` 파일 외에 `app.asar.unpacked` 폴더가
+같이 생성됩니다. 이 폴더안에 unpack 옵션에서 설정한 파일들이 압축이 풀려진 상태로
+포함되어 있습니다. 사용자에게 어플리케이션을 배포할 때 반드시 해당 폴더도 같이 배포해야
+합니다.
[asar]: https://github.com/atom/asar
# 메인 프로세스 디버깅하기
-브라우저 창의 개발자 도구는 웹 페이지 같은 랜더러 프로세스의 스크립트만 디버깅이 가능합니다.
-대신 Electron은 메인 프로세스의 디버깅을 위해 `--debug` 과 `--debug-brk` 스위치들을 제공합니다.
+브라우저 창의 개발자 도구는 웹 페이지 같은 랜더러 프로세스의 스크립트만 디버깅이
+가능합니다. 대신 Electron은 메인 프로세스의 디버깅을 위해 `--debug` 과 `--debug-brk`
+스위치들을 제공합니다.
## 커맨드 라인 스위치(command line switches)
### `--debug=[port]`
-이 스위치를 사용하면 Electron은 지정한 `port`에 V8 디버거 프로토콜을 리스닝합니다. 기본 `port`는 `5858` 입니다.
+이 스위치를 사용하면 Electron은 지정한 `port`에 V8 디버거 프로토콜을 리스닝합니다.
+기본 `port`는 `5858` 입니다.
### `--debug-brk=[port]`
## node-inspector로 디버깅 하기
-__참고:__ Electron은 node v0.11.13 버전을 사용합니다.
-그리고 현재 node-inspector 유틸리티와 호환성 문제가 있습니다.
-추가로 node-inspector 콘솔 내에서 메인 프로세스의 `process` 객체를 탐색할 경우 크래시가 발생할 수 있습니다.
+__참고:__ Electron은 node v0.11.13 버전을 사용합니다. 그리고 현재 node-inspector
+유틸리티와 호환성 문제가 있습니다. 추가로 node-inspector 콘솔 내에서 메인 프로세스의
+`process` 객체를 탐색할 경우 크래시가 발생할 수 있습니다.
### 1. [node-inspector][node-inspector] 서버 시작
### 3. 디버그 UI 로드
-Chrome 브라우저에서 http://127.0.0.1:8080/debug?ws=127.0.0.1:8080&port=5858 주소에 접속합니다. (기본포트 또는 지정한 포트로 접속)
+Chrome 브라우저에서 http://127.0.0.1:8080/debug?ws=127.0.0.1:8080&port=5858 주소에
+접속합니다. (기본포트 또는 지정한 포트로 접속)
[node-inspector]: https://github.com/node-inspector/node-inspector
# 데스크톱 환경 통합
-어플리케이션 배포의 대상이 되는 서로 다른 운영체제 시스템의 환경에 맞춰 어플리케이션의 기능을 통합할 수 있습니다.
-예를 들어 Windows에선 태스크바의 JumpList에 바로가기를 추가할 수 있고 Mac(OS X)에선 dock 메뉴에 커스텀 메뉴를 추가할 수 있습니다.
+어플리케이션 배포의 대상이 되는 서로 다른 운영체제 시스템의 환경에 맞춰 어플리케이션의
+기능을 통합할 수 있습니다. 예를 들어 Windows에선 태스크바의 JumpList에 바로가기를
+추가할 수 있고 Mac(OS X)에선 dock 메뉴에 커스텀 메뉴를 추가할 수 있습니다.
-이 문서는 Electron API를 이용하여 각 운영체제 시스템의 기능을 활용하는 방법을 설명합니다.
+이 문서는 Electron API를 이용하여 각 운영체제 시스템의 기능을 활용하는 방법을
+설명합니다.
## 데스크톱 알림 (Windows, Linux, OS X)
-Windows, Linux, OS X 운영체제 모두 기본적으로 어플리케이션에서 유저에게 알림 보낼 수 있는 방법을 제공합니다.
-Electron은 HTML5 Notification API](https://notifications.spec.whatwg.org/)를 통해 개발자가
-편리하게 데스크톱 알림을 사용할 수 있는 기능을 제공합니다. 데스크톱 알림은 운영체제의 네이티브 알림 API를 사용하여 표시합니다.
+Windows, Linux, OS X 운영체제 모두 기본적으로 어플리케이션에서 유저에게 알림을 보내는
+방법을 제공합니다. Electron은 [HTML5 Notification API](https://notifications.spec.whatwg.org/)를
+통해 개발자가 편리하게 데스크톱 알림을 사용할 수 있는 기능을 제공합니다. 데스크톱 알림은
+운영체제의 네이티브 알림 API를 사용하여 표시합니다.
```javascript
var myNotification = new Notification('Title', {
}
```
-위 코드를 통해 생성한 데스크톱 알림은 각 운영체제 모두 비슷한 사용자 경험을 제공합니다. 하지만 몇 가지 다른 점들이 있습니다.
+위 코드를 통해 생성한 데스크톱 알림은 각 운영체제 모두 비슷한 사용자 경험을 제공합니다.
+하지만 몇 가지 다른 점들이 있습니다.
### Windows
* Windows 10에선 "아무 문제 없이 잘" 작동합니다.
-* Windows 8.1과 8에선 [Application User Model ID][app-user-model-id]로 바로가기를 만들어 놔야 합니다.
-이 바로가기는 반드시 시작 화면에 설치되어 있어야 합니다. 참고로 반드시 시작 화면에 고정 할 필요는 없습니다.
-* Windows 7과 그 이하 버전은 데스크톱 알림을 지원하지 않습니다. 혹시 "풍선 팝업 알림" 기능을 찾는다면 [Tray API](tray-balloon)를 사용하세요.
+* Windows 8.1과 8에선 [Application User Model ID][app-user-model-id]로 바로가기를
+ 만들어 놔야 합니다. 이 바로가기는 반드시 시작 화면에 설치되어 있어야 합니다. 참고로
+ 반드시 시작 화면에 고정 할 필요는 없습니다.
+* Windows 7과 그 이하 버전은 데스크톱 알림을 지원하지 않습니다.
+ 혹시 "풍선 팝업 알림" 기능을 찾는다면 [Tray API](tray-balloon)를 사용하세요.
-이미지를 데스크톱 알림에 사용하려면 알림 옵션의 `icon` 속성에 로컬 이미지 파일(`png` 권장)을 지정하면 됩니다.
-데스크톱 알림은 잘못된 경로를 지정하거나 `http/https` 기반의 URL을 지정해도 이미지가 보이지 않을 뿐 정상 작동합니다.
+이미지를 데스크톱 알림에 사용하려면 알림 옵션의 `icon` 속성에 로컬 이미지 파일
+(`png` 권장)을 지정하면 됩니다. 데스크톱 알림은 잘못된 경로를 지정하거나 `http/https`
+기반의 URL을 지정해도 이미지가 보이지 않을 뿐 정상 작동합니다.
```javascript
new Notification('Title', {
});
```
-또한 `body`의 최대 길이는 250자 입니다. Windows 개발팀에선 알림 문자열을 200자 이하로 유지하는 것을 권장합니다.
+또한 `body`의 최대 길이는 250자 입니다. Windows 개발팀에선 알림 문자열을 200자 이하로
+유지하는 것을 권장합니다.
### Linux
데스크톱 알림의 구현으로 `libnotify`를 사용합니다. 따라서 [Desktop Notifications Specification][notification-spec]을
-따르는 모든 데스크탑 환경에서 데스크톱 알림 기능을 사용할 수 있습니다. Cinnamon, Enlightenment, Unity, GNOME, KDE등을 지원합니다.
+따르는 모든 데스크탑 환경에서 데스크톱 알림 기능을 사용할 수 있습니다. Cinnamon,
+Enlightenment, Unity, GNOME, KDE등을 지원합니다.
### OS X
[Apple's Human Interface guidelines regarding notifications](https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/NotificationCenter.html)
가이드를 고려해야 합니다.
-참고로 데스크롭 알림의 최대 길이는 256 바이트 입니다. 길이가 초과할 경우 초과한 글자가 잘립니다.
+참고로 데스크롭 알림의 최대 길이는 256 바이트 입니다. 길이가 초과할 경우 초과한 글자가
+잘립니다.
## 최근 사용한 문서 (Windows & OS X)
-알다 싶이 Windows와 OS X는 JumpList 또는 dock 메뉴를 통해 최근 문서 리스트에 쉽게 접근할 수 있습니다.
+알다 싶이 Windows와 OS X는 JumpList 또는 dock 메뉴를 통해 최근 문서 리스트에 쉽게
+접근할 수 있습니다.
__JumpList:__
<img src="https://cloud.githubusercontent.com/assets/639601/5069610/2aa80758-6e97-11e4-8cfb-c1a414a10774.png" height="353" width="428" >
-파일을 최근 문서에 추가하려면 [app.addRecentDocument][addrecentdocument] API를 사용할 수 있습니다:
+파일을 최근 문서에 추가하려면 [app.addRecentDocument][addrecentdocument] API를
+사용할 수 있습니다:
```javascript
app.addRecentDocument('/Users/USERNAME/Desktop/work.type');
```
-그리고 [app.clearRecentDocuments][clearrecentdocuments] API로 최근 문서 리스트를 비울 수 있습니다:
+그리고 [app.clearRecentDocuments][clearrecentdocuments] API로 최근 문서 리스트를
+비울 수 있습니다:
```javascript
app.clearRecentDocuments();
### Windows에서 주의할 점
-이 기능을 Windows에서 사용할 땐 운영체제 시스템에 어플리케이션에서 사용하는 파일 확장자가 등록되어 있어야 합니다.
-그렇지 않은 경우 파일을 JumpList에 추가해도 추가되지 않습니다.
-어플리케이션 등록에 관련된 API의 모든 내용은 [Application Registration][app-registration]에서 찾아볼 수 있습니다.
+이 기능을 Windows에서 사용할 땐 운영체제 시스템에 어플리케이션에서 사용하는 파일
+확장자가 등록되어 있어야 합니다. 그렇지 않은 경우 파일을 JumpList에 추가해도 추가되지
+않습니다. 어플리케이션 등록에 관련된 API의 모든 내용은 [Application Registration][app-registration]에서
+찾아볼 수 있습니다.
-유저가 JumpList에서 파일을 클릭할 경우 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어 새로운 인스턴스의 어플리케이션이 실행됩니다.
+유저가 JumpList에서 파일을 클릭할 경우 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어
+새로운 인스턴스의 어플리케이션이 실행됩니다.
### OS X에서 주의할 점
<img src="https://cloud.githubusercontent.com/assets/639601/5069962/6032658a-6e9c-11e4-9953-aa84006bdfff.png" height="354" width="341" >
-커스텀 dock menu를 설정하려면 `app.dock.setMenu` API를 사용하면 됩니다. OS X에서만 사용 가능합니다:
+커스텀 dock menu를 설정하려면 `app.dock.setMenu` API를 사용하면 됩니다.
+OS X에서만 사용 가능합니다:
```javascript
const electron = require('electron');
Windows에선 JumpList의 `Tasks` 카테고리에 원하는 작업을 설정할 수 있습니다.
MSDN에선 해당 기능을 다음과 같이 설명하고 있습니다:
-> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을 예측하여 정의합니다.
-> 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시 context-free를 유지해야 합니다.
-> 작업은 일반 사용자가 프로그램을 실행하거나 이메일 프로그램으로 이메일을 작성하거나 달력을 불러오고
-> 워드 프로세서로 새 문서를 작성, 특정 모드, 부속 명령으로 프로그램을 실행하는 등의
-> 통계적, 일반적으로 가장 많이 사용되는 작업인지를 고려해야 합니다.
-> 어플리케이션 작업은 일반 유저가 필요로 하지 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다.
-> 작업에 특별 이벤트 또는 업그레이드 등의 홍보성 작업을 추가하면 안됩니다.
+> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을
+> 예측하여 정의합니다. 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시
+> context-free를 유지해야 합니다. 작업은 일반 사용자가 프로그램을 실행하거나 이메일
+> 프로그램으로 이메일을 작성하거나 달력을 불러오고, 워드 프로세서로 새 문서를 작성,
+> 특정 모드, 부속 명령으로 프로그램을 실행하는 등의 통계적, 일반적으로 가장 많이
+> 사용되는 작업인지를 고려해야 합니다. 어플리케이션 작업은 일반 유저가 필요로 하지
+> 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다.
+> 또한 작업에 특별 이벤트 또는 업그레이드 등의 홍보성 작업을 추가하면 안됩니다.
>
> 작업 리스트는 가능한 한 정적으로 유지되는 것을 적극 권장합니다.
> 이것은 동일한 상태 또는 응용 프로그램의 상태에 관계없이 유지되어야 합니다.
-> 작업 목록은 동적으로 변경할 수 있지만 몇몇 유저는 예상하지 못한 작업 목록 변경에 혼동할 수 있다는 점을 고려해야 합니다.
+> 작업 목록은 동적으로 변경할 수 있지만 몇몇 유저는 예상하지 못한 작업 목록 변경에
+> 혼란을 일으킬 수 있다는 점을 고려해야 합니다.
__Internet Explorer의 작업:__
-OS X의 dock menu(진짜 메뉴)와는 달리 Windows의 사용자 작업은 어플리케이션 바로 가기처럼 작동합니다.
-유저가 작업을 클릭할 때 설정한 인자와 함께 새로운 어플리케이션이 실행됩니다.
+OS X의 dock menu(진짜 메뉴)와는 달리 Windows의 사용자 작업은 어플리케이션 바로
+가기처럼 작동합니다. 유저가 작업을 클릭할 때 설정한 인자와 함께 새로운 어플리케이션이
+실행됩니다.
-사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] 메서드를 통해 구현할 수 있습니다:
+사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] 메서드를 통해 구현할
+수 있습니다:
```javascript
app.setUserTasks([
]);
```
-작업 리스트를 비우려면 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어 호출하면 됩니다:
+작업 리스트를 비우려면 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어
+호출하면 됩니다:
```javascript
app.setUserTasks([]);
```
-사용자 작업 리스트는 어플리케이션이 삭제되지 않는 한 종료되어도 태스크바에 보존됩니다. 이러한 이유로 반드시 프로그램 경로와 아이콘 경로를 지정해야 합니다.
+사용자 작업 리스트는 어플리케이션이 삭제되지 않는 한 종료되어도 태스크바에 보존됩니다.
+이러한 이유로 반드시 프로그램 경로와 아이콘 경로를 지정해야 합니다.
-## 섬네일 툴바
+## 미리보기 툴바
-Windows에선 작업 표시줄의 어플리케이션 선택시 나오는 미리보기에 특정한 섬네일 툴바를 추가할 수 있습니다.
-이 기능은 유저가 윈도우를 활성화 하지 않고 특정한 커맨드를 실행시킬 수 있도록 할 수 있습니다.
+Windows에선 작업 표시줄의 어플리케이션 선택시 나오는 미리보기에 특정한 미리보기 툴바를
+추가할 수 있습니다. 이 기능은 유저가 윈도우를 활성화 하지 않고 특정한 커맨드를 실행시킬
+수 있도록 할 수 있습니다.
MSDN의 설명에 의하면:
-> 이 툴바는 표준 툴바의 공통 컨트롤과 비슷한 역할을 합니다. 버튼은 최대 7개 까지 만들 수 있습니다.
-> 각 버튼의 구조엔 ID, 이미지, 툴팁, 상태등이 정의되어있습니다. 태스크바에 구조가 전달되면 어플리케이션이
-> 상태에 따라 버튼을 숨기거나, 활성화하거나, 비활성화 할 수 있습니다.
+> 이 툴바는 표준 툴바의 공통 컨트롤과 비슷한 역할을 합니다. 버튼은 최대 7개 까지
+> 만들 수 있습니다. 각 버튼의 구조엔 ID, 이미지, 툴팁, 상태 등이 정의되어있습니다.
+> 작업표시줄에 구조가 전달되면 어플리케이션이 상태에 따라 버튼을 숨기거나, 활성화하거나,
+> 비활성화 할 수 있습니다.
>
-> 예를 들어, 윈도우 미디어 플레이어는(WMP) 기본적으로
-> 미디어 플레이어가 공통적으로 사용하는 재생, 일시정지, 음소거, 정지등의 컨트롤을 포함하고 있습니다.
+> 예를 들어, 윈도우 미디어 플레이어는(WMP) 미디어 플레이어가 공통적으로 사용하는
+> 재생, 일시정지, 음소거, 정지등의 컨트롤을 포함하고 있습니다.
-__Windows Media Player의 섬네일 툴바:__
+__Windows Media Player의 미리보기 툴바:__
-[BrowserWindow.setThumbarButtons][setthumbarbuttons] API를 통해 어플리케이션에 섬네일 툴바를 설정할 수 있습니다:
+[BrowserWindow.setThumbarButtons][setthumbarbuttons] API를 통해 어플리케이션에
+미리보기 툴바를 설정할 수 있습니다:
```javascript
const BrowserWindow = require('electron').BrowserWindow;
]);
```
-섬네일 툴바를 비우려면 간단히 `BrowserWindow.setThumbarButtons` API에 빈 배열을 전달하면 됩니다:
+미리보기 툴바를 비우려면 간단히 `BrowserWindow.setThumbarButtons` API에 빈 배열을
+전달하면 됩니다:
```javascript
win.setThumbarButtons([]);
## Unity 런처 숏컷 기능 (Linux)
-Unity 환경에선 `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding Shortcuts to a Launcher][unity-launcher] 가이드를 참고하세요.
+Unity 환경에선 `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수
+있습니다. [Adding Shortcuts to a Launcher][unity-launcher] 가이드를 참고하세요.
__Audacious의 런처 숏컷:__
## Taskbar progress 기능 (Windows & Unity)
Windows에선 태스크바의 어플리케이션 버튼에 progress bar를 추가할 수 있습니다.
-이 기능은 사용자가 어플리케이션의 창을 열지 않고도 어플리케이션의 작업의 상태 정보를 시각적으로 보여줄 수 있도록 해줍니다.
+이 기능은 사용자가 어플리케이션의 창을 열지 않고도 어플리케이션의 작업의 상태 정보를
+시각적으로 보여줄 수 있도록 해줍니다.
또한 Unity DE도 런처에 progress bar를 부착할 수 있습니다.
-이 기능은 [BrowserWindow.setProgressBar][setprogressbar] API를 사용하여 구현할 수 있습니다:
+이 기능은 [BrowserWindow.setProgressBar][setprogressbar] API를 사용하여 구현할 수
+있습니다:
```javascript
var window = new BrowserWindow({...});
## 대표 파일 제시 (OS X)
-OS X는 창에서 대표 파일을 설정할 수 있습니다. 타이틀바에서 파일 아이콘이 있고, 사용자가 Command-Click 또는 Control-Click 키를 누를 경우 파일 경로 팝업이 보여집니다.
-또한 창의 상태도 지정할 수 있습니다. 쉽게 말해 로드된 문서의 수정여부를 타이틀바 파일 아이콘에 표시할 수 있습니다.
+OS X는 창에서 대표 파일을 설정할 수 있습니다. 타이틀바에서 파일 아이콘이 있고, 사용자가
+Command-Click 또는 Control-Click 키를 누를 경우 파일 경로 팝업이 보여집니다. 또한
+창의 상태도 지정할 수 있습니다. 다시 말해 로드된 문서의 수정 여부를 제목의 파일
+아이콘에 표시할 수 있습니다.
__대표 파일 팝업 메뉴:__
<img src="https://cloud.githubusercontent.com/assets/639601/5082061/670a949a-6f14-11e4-987a-9aaa04b23c1d.png" height="232" width="663" >
-대표 파일 관련 API는 [BrowserWindow.setRepresentedFilename][setrepresentedfilename] 과 [BrowserWindow.setDocumentEdited][setdocumentedited]를 사용할 수 있습니다:
+대표 파일 관련 API는 [BrowserWindow.setRepresentedFilename][setrepresentedfilename] 과
+[BrowserWindow.setDocumentEdited][setdocumentedited]를 사용할 수 있습니다:
```javascript
var window = new BrowserWindow({...});
# 개발자 도구 확장 기능
-어플리케이션의 디버깅을 쉽게 하기 위해 Electron은 기본적으로 [Chrome DevTools Extension][devtools-extension]을 지원합니다.
+어플리케이션의 디버깅을 쉽게 하기 위해 Electron은 기본적으로
+[Chrome DevTools Extension][devtools-extension]을 지원합니다.
-개발자 도구 확장 기능은 간단하게 사용할 확장 기능 플러그인의 소스 코드를 다운로드한 후 `BrowserWindow.addDevToolsExtension` API를 이용하여
-어플리케이션 내에 로드할 수 있습니다. 한가지 주의할 점은 확장 기능 사용시 창이 생성될 때 마다 일일이 해당 API를 호출할 필요는 없습니다.
+개발자 도구 확장 기능은 간단하게 사용할 확장 기능 플러그인의 소스 코드를 다운로드한 후
+`BrowserWindow.addDevToolsExtension` API를 통해 어플리케이션 내에 로드할 수 있습니다.
+한가지 주의할 점은 확장 기능 사용시 창이 생성될 때 마다 일일이 해당 API를 호출할 필요는
+없습니다.
-** 주의: 현재 React DevTools은 작동하지 않습니다. https://github.com/atom/electron/issues/915 이슈를 참고하세요! **
+**주의: 현재 React DevTools은 작동하지 않습니다. https://github.com/atom/electron/issues/915 이슈를 참고하세요!**
-다음 예제는 [React DevTools Extension](https://github.com/facebook/react-devtools)을 사용합니다.
+다음 예제는 [React DevTools Extension](https://github.com/facebook/react-devtools)을
+사용합니다.
먼저 소스코드를 다운로드 받습니다:
$ git clone --recursive https://github.com/facebook/react-devtools.git
```
-[`react-devtools/shells/chrome/Readme.md`](https://github.com/facebook/react-devtools/blob/master/shells/chrome/Readme.md)
-를 통해 확장 기능을 개발하는 방법을 알아볼 수 있습니다.
+[`react-devtools/shells/chrome/Readme.md`](https://github.com/facebook/react-devtools/blob/master/shells/chrome/Readme.md)를
+통해 확장 기능을 개발하는 방법을 알아볼 수 있습니다.
그리고 개발자 도구에서 다음 코드를 입력하면 확장 기능을 로드할 수 있습니다:
BrowserWindow.addDevToolsExtension('/some-directory/react-devtools/shells/chrome');
```
-확장 기능을 언로드 하고 콘솔을 다시 열 때 해당 확장 기능이 로드되지 않도록 하려면 `BrowserWindow.removeDevToolsExtension` API를 사용하면 됩니다:
+확장 기능을 언로드 하고 콘솔을 다시 열 때 해당 확장 기능이 로드되지 않도록 하려면
+`BrowserWindow.removeDevToolsExtension` API를 사용하면 됩니다:
```javascript
BrowserWindow.removeDevToolsExtension('React Developer Tools');
## 개발자 도구 확장 기능의 구성 형식
-모든 개발자 도구 확장은 완벽히 Chrome 브라우저를 위해 작성되었기 때문에 Electron에서도 로드할 수 있습니다.
-하지만 반드시 확장 기능은 소스 코드 디렉터리(폴더) 형태여야 합니다. 그래서 `crx` 등의 포맷으로 패키징된 확장 기능의 경우
-사용자가 직접 해당 패키지의 압축을 풀어서 로드하지 않는 이상 Electron에서 해당 확장 기능의 압축을 풀 방법이 없습니다.
+모든 개발자 도구 확장은 완벽히 Chrome 브라우저를 위해 작성되었기 때문에 Electron에서도
+로드할 수 있습니다. 하지만 반드시 확장 기능은 소스 코드 디렉터리(폴더) 형태여야 합니다.
+그래서 `crx` 등의 포맷으로 패키징된 확장 기능의 경우 사용자가 직접 해당 패키지의 압축을
+풀어서 로드하지 않는 이상 Electron에서 해당 확장 기능의 압축을 풀 방법이 없습니다.
## 백그라운드 페이지
-현재 Electron은 Chrome에서 지원하는 백그라운드 페이지(background pages)를 지원하지 않습니다.
-몇몇 확장 기능은 이 기능에 의존하는 경우가 있는데, 이 때 해당 확장 기능은 Electron에서 작동하지 않을 수 있습니다.
+현재 Electron은 Chrome에서 지원하는 백그라운드 페이지(background pages)를 지원하지
+않습니다. 몇몇 확장 기능은 이 기능에 의존하는 경우가 있는데, 이 때 해당 확장 기능은
+Electron에서 작동하지 않을 수 있습니다.
## `chrome.*` API
-몇몇 Chrome 확장 기능은 특정 기능을 사용하기 위해 `chrome.*` API를 사용하는데, 이 API들을 구현하기 위해 노력했지만 안타깝게도 아직 모든 API가 구현되지는 않았습니다.
+몇몇 Chrome 확장 기능은 특정 기능을 사용하기 위해 `chrome.*` API를 사용하는데, 이
+API들을 구현하기 위해 노력했지만 안타깝게도 아직 모든 API가 구현되지는 않았습니다.
-아직 모든 API가 구현되지 않았기 때문에 확장 기능에서 `chrome.devtools.*` 대신 `chrome.*` API를 사용할 경우 확장 기능이 제대로 작동하지 않을 수 있음을 감안해야 합니다.
-만약 문제가 발생할 경우 Electron의 GitHub 저장소에 관련 이슈를 올리면 해당 API를 추가하는데 많은 도움이 됩니다.
+아직 모든 API가 구현되지 않았기 때문에 확장 기능에서 `chrome.devtools.*` 대신
+`chrome.*` API를 사용할 경우 확장 기능이 제대로 작동하지 않을 수 있음을 감안해야 합니다.
+만약 문제가 발생할 경우 Electron의 GitHub 저장소에 관련 이슈를 올리면 해당 API를
+추가하는데 많은 도움이 됩니다.
[devtools-extension]: https://developer.chrome.com/extensions/devtools
# Mac 앱 스토어 어플리케이션 제출 가이드
-Electron은 v0.34.0 버전부터 앱 패키지를 Mac App Store(MAS)에 제출할 수 있게 되었습니다.
-이 가이드는 어플리케이션을 앱 스토어에 등록하는 방법과 빌드의 한계에 대한 설명을 제공합니다.
+Electron은 v0.34.0 버전부터 앱 패키지를 Mac App Store(MAS)에 제출할 수 있게
+되었습니다. 이 가이드는 어플리케이션을 앱 스토어에 등록하는 방법과 빌드의 한계에 대한
+설명을 제공합니다.
## 앱 스토어에 어플리케이션을 등록하는 방법
다음 몇 가지 간단한 절차에 따라 앱 스토어에 어플리케이션을 등록하는 방법을 알아봅니다.
-한가지, 이 절차는 제출한 앱이 Apple로부터 승인된다는 것을 확신하지 않습니다.
-따라서 여전히 Apple의 [Submitting Your App][submitting-your-app] 가이드를 숙지하고 있어야 하며
-앱 스토어 제출 요구 사항을 확실히 인지하고 있어야합니다.
+한가지, 이 절차는 제출한 앱이 Apple로부터 승인된다는 것을 확신하지 않습니다. 따라서
+여전히 Apple의 [Submitting Your App][submitting-your-app] 가이드를 숙지하고 있어야
+하며 앱 스토어 제출 요구 사항을 확실히 인지하고 있어야합니다.
### 인증서 취득
-앱 스토어에 어플리케이션을 제출하려면, 먼저 Apple로부터 인증서를 취득해야 합니다.
-취득 방법은 웹에서 찾아볼 수 있는 [가이드][nwjs-guide]를 참고하면 됩니다.
+앱 스토어에 어플리케이션을 제출하려면, 먼저 Apple로부터 인증서를 취득해야 합니다. 취득
+방법은 웹에서 찾아볼 수 있는 [가이드][nwjs-guide]를 참고하면 됩니다.
### 앱에 서명하기
-Apple로부터 인증서를 취득했다면, [어플리케이션 배포](application-distribution.md) 문서에 따라 어플리케이션을 패키징한 후 어플리케이션에 서명 합니다.
-이 절차는 기본적으로 다른 프로그램과 같습니다. 하지만 키는 Electron 종속성 파일에 각각 따로 서명 해야 합니다.
+Apple로부터 인증서를 취득했다면, [어플리케이션 배포](application-distribution.md)
+문서에 따라 어플리케이션을 패키징한 후 어플리케이션에 서명 합니다. 이 절차는 기본적으로
+다른 프로그램과 같습니다. 하지만 키는 Electron 종속성 파일에 각각 따로 서명 해야 합니다.
첫번째, 다음 두 자격(plist) 파일을 준비합니다.
productbuild --component "$APP_PATH" /Applications --sign "$INSTALLER_KEY" "$RESULT_PATH"
```
-만약 OS X의 샌드박스 개념에 대해 처음 접한다면 Apple의 [Enabling App Sandbox][enable-app-sandbox] 문서를
-참고하여 기본적인 개념을 이해해야 합니다. 그리고 자격(plist) 파일에 어플리케이션에서 요구하는 권한의 키를 추가합니다.
+만약 OS X의 샌드박스 개념에 대해 처음 접한다면 Apple의 [Enabling App Sandbox][enable-app-sandbox]
+문서를 참고하여 기본적인 개념을 이해해야 합니다. 그리고 자격(plist) 파일에
+어플리케이션에서 요구하는 권한의 키를 추가합니다.
### 어플리케이션을 업로드하고 심사용 앱으로 제출
-어플리케이션 서명을 완료한 후 iTunes Connect에 업로드하기 위해 Application Loader를 사용할 수 있습니다.
-ì°¸ê³ ë¡\9c ì\97\85ë¡\9cë\93\9cí\95\98기 ì \84ì\97\90 [ë \88ì½\94ë\93\9c][create-record]를 ë§\8cë\93¤ì\97\88ë\8a\94ì§\80 í\99\95ì\9d¸í\95´ì\95¼ í\95©ë\8b\88ë\8b¤.
-그리고 [심사를 위해 앱을 제출][submit-for-review]할 수 있습니다.
+어플리케이션 서명을 완료한 후 iTunes Connect에 업로드하기 위해 Application Loader를
+ì\82¬ì\9a©í\95 ì\88\98 ì\9e\88ì\8aµë\8b\88ë\8b¤. ì°¸ê³ ë¡\9c ì\97\85ë¡\9cë\93\9cí\95\98기 ì \84ì\97\90 [ë \88ì½\94ë\93\9c][create-record]를 ë§\8cë\93¤ì\97\88ë\8a\94ì§\80
+확인해야 합니다. 그리고 [심사를 위해 앱을 제출][submit-for-review]할 수 있습니다.
## MAS 빌드의 한계
-모든 어플리케이션 샌드박스에 대한 요구 사항을 충족시키기 위해, 다음 모듈들은 MAS 빌드에서 비활성화됩니다:
+모든 어플리케이션 샌드박스에 대한 요구 사항을 충족시키기 위해, 다음 모듈들은 MAS
+빌드에서 비활성화됩니다:
* `crash-reporter`
* `auto-updater`
* 특정 접근성 기능이 작동하지 않을 수 있습니다.
* 어플리케이션이 DNS의 변경을 감지하지 못할 수 있습니다.
-또한 어플리케이션 샌드박스 개념으로 인해 어플리케이션에서 접근할 수 있는 리소스는 엄격하게 제한되어 있습니다.
-자세한 내용은 [App Sandboxing][app-sandboxing] 문서를 참고하세요.
+또한 어플리케이션 샌드박스 개념으로 인해 어플리케이션에서 접근할 수 있는 리소스는
+엄격하게 제한되어 있습니다. 자세한 내용은 [App Sandboxing][app-sandboxing] 문서를
+참고하세요.
**역주:** [Mac 앱 배포 가이드 공식 문서](https://developer.apple.com/osx/distribution/kr/)
# 온라인/오프라인 이벤트 감지
-온라인/오프라인 이벤트는 다음 예제와 같이 랜더러 프로세스에서 표준 HTML5 API를 이용하여 구현할 수 있습니다.
+온라인/오프라인 이벤트는 다음 예제와 같이 랜더러 프로세스에서 표준 HTML5 API를 이용하여
+구현할 수 있습니다.
_main.js_
</html>
```
-메인 프로세스에서 이 이벤트를 처리할 필요가 있는 경우 이벤트를 메인 프로세스로 보낼 수 있습니다.
-메인 프로세스는 `navigator` 객체를 가지고 있지 않기 때문에 이 이벤트를 직접 사용할 수 없습니다.
+메인 프로세스에서 이 이벤트를 처리할 필요가 있는 경우 이벤트를 메인 프로세스로 보낼 수
+있습니다. 메인 프로세스는 `navigator` 객체를 가지고 있지 않기 때문에 이 이벤트를 직접
+사용할 수는 없습니다.
-대신 다음 예제와 같이 Electron의 inter-process communication(ipc) 유틸리티를 사용하면 이벤트를 메인 프로세스로 전달할 수 있습니다.
+대신 다음 예제와 같이 Electron의 inter-process communication(ipc) 유틸리티를
+사용하면 이벤트를 메인 프로세스로 전달할 수 있습니다.
_main.js_
## 소개
-Electron은 자바스크립트와 함께 제공된 풍부한 네이티브 API를 사용하여 멋진 데스크탑 어플리케이션을 만들 수 있도록 해주는 프레임워크입니다.
-이 프레임워크의 Node.js는 웹 서버 개발이 아닌 데스크탑 어플리케이션 개발에 초점을 맞췄습니다.
+Electron은 자바스크립트와 함께 제공된 풍부한 네이티브 API를 사용하여 멋진 데스크탑
+어플리케이션을 만들 수 있도록 해주는 프레임워크입니다. 이 프레임워크의 Node.js는 웹
+서버 개발이 아닌 데스크탑 어플리케이션 개발에 초점을 맞췄습니다.
-이 말은 Electron이 GUI 라이브러리의 자바스크립트 바인딩이라는 뜻이 아닙니다.
-대신, Electron은 웹 페이지의 GUI를 사용합니다. 쉽게 말해 Electron은 자바스크립트를 사용하여 조작하는 작은 Chromium 브라우저로 볼 수 있습니다.
+이 말은 Electron이 GUI 라이브러리의 자바스크립트 바인딩이라는 뜻이 아닙니다. 대신,
+Electron은 웹 페이지의 GUI를 사용합니다. 쉽게 말해 Electron은 자바스크립트를 사용하여
+조작하는 작은 Chromium 브라우저로 볼 수 있습니다.
### 메인 프로세스
-Electron은 실행될 때 __메인 프로세스__로 불리는 `package.json`의 `main` 스크립트를 호출합니다.
-이 스크립트는 메인 프로세스에서 작동합니다. GUI 컴포넌트를 조작하거나 웹 페이지 창을 생성할 수 있습니다.
+Electron은 실행될 때 __메인 프로세스__로 불리는 `package.json`의 `main` 스크립트를
+호출합니다. 이 스크립트는 메인 프로세스에서 작동합니다. GUI 컴포넌트를 조작하거나 웹
+페이지 창을 생성할 수 있습니다.
### 랜더러 프로세스
Electron이 웹페이지를 보여줄 때 Chromium의 multi-processes 구조도 같이 사용됩니다.
Electron 프로세스 내에서 작동하는 웹 페이지를 __랜더러 프로세스__ 라고 불립니다.
-보통 일반 브라우저의 웹 페이지들은 샌드박스가 적용된 환경에서 작동하며 네이티브 리소스에는 접근할 수 없도록 되어 있습니다.
-하지만 Electron은 웹 페이지 내에서 Node.js API를 사용하여 low-level 수준으로 운영체제와 상호작용할 수 있습니다.
+보통 일반 브라우저의 웹 페이지들은 샌드박스가 적용된 환경에서 작동하며 네이티브
+리소스에는 접근할 수 없도록 되어 있습니다. 하지만 Electron은 웹 페이지 내에서 Node.js
+API를 사용하여 low-level 수준으로 운영체제와 상호작용할 수 있습니다.
### 메인 프로세스와 랜더러 프로세스의 차이점
메인 프로세스는 `BrowserWindow` Class를 사용하여 새로운 창을 만들 수 있습니다.
-`BrowserWindow` 인스턴스는 따로 분리된 프로세스에서 랜더링 되며 이 프로세스를 랜더러 프로세스라고 합니다.
-`BrowserWindow` 인스턴스가 소멸할 때 그 창의 랜더러 프로세스도 같이 소멸합니다.
+`BrowserWindow` 인스턴스는 따로 분리된 프로세스에서 랜더링 되며 이 프로세스를 랜더러
+프로세스라고 합니다. `BrowserWindow` 인스턴스가 소멸할 때 그 창의 랜더러 프로세스도
+같이 소멸합니다.
-메인 프로세스는 모든 웹 페이지와 랜더러 프로세스를 관리하며 랜더러 프로세스는 각각의 프로세스에 고립되며 웹 페이지의 작동에만 영향을 끼칩니다.
+메인 프로세스는 모든 웹 페이지와 랜더러 프로세스를 관리하며 랜더러 프로세스는 각각의
+프로세스에 고립되며 웹 페이지의 작동에만 영향을 끼칩니다.
-웹 페이지 내에선 기본적으로 네이티브 GUI와 관련된 API를 호출할 수 없도록 설계 되어 있습니다.
-왜냐하면 웹 페이지 내에서 네이티브 GUI 리소스를 관리하는 것은 보안에 취약하고 리소스를 누수시킬 수 있기 때문입니다.
-꼭 웹 페이지 내에서 API를 사용해야 한다면 메인 프로세스에서 그 작업을 처리할 수 있도록 메인 프로세스와 통신을 해야 합니다.
+웹 페이지 내에선 기본적으로 네이티브 GUI와 관련된 API를 호출할 수 없도록 설계 되어
+있습니다. 왜냐하면 웹 페이지 내에서 네이티브 GUI 리소스를 관리하는 것은 보안에 취약하고
+리소스를 누수시킬 수 있기 때문입니다. 꼭 웹 페이지 내에서 API를 사용해야 한다면 메인
+프로세스에서 그 작업을 처리할 수 있도록 메인 프로세스와 통신을 해야 합니다.
-Electron에는 메인 프로세스와 랜더러 프로세스 사이에 통신을 할 수 있도록 [ipc](../api/ipc-renderer.md) 모듈을 제공하고 있습니다.
+Electron에는 메인 프로세스와 랜더러 프로세스 사이에 통신을 할 수 있도록
+[ipc](../api/ipc-renderer.md) 모듈을 제공하고 있습니다.
또는 [remote](../api/remote.md) 모듈을 사용하여 RPC 스타일로 통신할 수도 있습니다.
## 첫번째 Electron 앱 만들기
└── index.html
```
-`package.json`은 node 모듈의 package.json과 같습니다.
-그리고 `main` 필드에 스크립트 파일을 지정하면 메인 프로세스의 엔트리 포인트로 사용합니다.
-예를 들어 사용할 수 있는 `package.json`은 다음과 같습니다:
+`package.json`은 node 모듈의 package.json과 같습니다. 그리고 `main` 필드에 스크립트
+파일을 지정하면 메인 프로세스의 엔트리 포인트로 사용합니다. 예를 들어 사용할 수 있는
+`package.json`은 다음과 같습니다:
```json
{
}
```
-__알림__: 만약 `main` 필드가 `package.json`에 설정되어 있지 않으면 Electron은 자동으로 같은 디렉터리의 `index.js`를 로드합니다.
+__알림__: 만약 `main` 필드가 `package.json`에 설정되어 있지 않으면 Electron은
+자동으로 같은 디렉터리의 `index.js`를 로드합니다.
-반드시 `main.js`에서 창을 만들고 시스템 이밴트를 처리해야합니다. 대표적인 예제로 다음과 같이 작성할 수 있습니다:
+반드시 `main.js`에서 창을 만들고 시스템 이밴트를 처리해야합니다. 대표적인 예제로
+다음과 같이 작성할 수 있습니다:
```javascript
const electron = require('electron');
## 앱 실행하기
-앱을 작성한 후 [어플리케이션 배포](application-distribution.md) 가이드를 따라 앱을 패키징 하고 패키징한 앱을 실행할 수 있습니다.
-또한 Electron 실행파일을 다운로드 받아 바로 실행해 볼 수도 있습니다.
+앱을 작성한 후 [어플리케이션 배포](application-distribution.md) 가이드를 따라 앱을
+패키징 하고 패키징한 앱을 실행할 수 있습니다. 또한 Electron 실행파일을 다운로드 받아
+바로 실행해 볼 수도 있습니다.
### electron-prebuilt 사용
-`npm`을 통해 `electron-prebuilt` 패키지를 전역에 설치하면 간단한 명령으로 앱을 실행할 수 있습니다.
+`npm`을 통해 `electron-prebuilt` 패키지를 전역에 설치하면 간단한 명령으로 앱을
+실행할 수 있습니다.
앱 디렉터리 내에서 다음 명령으로 실행할 수 있습니다:
### 배포용 실행 파일 만들기
-어플리케이션 작성을 모두 끝냈다면 [어플리케이션 배포](application-distribution.md) 가이드를 통해 제작한 앱을 패키징하고 배포할 수 있습니다.
+어플리케이션 작성을 모두 끝냈다면 [어플리케이션 배포](application-distribution.md)
+가이드를 통해 제작한 앱을 패키징하고 배포할 수 있습니다.
### 미리 작성된 앱 실행하기
-[`atom/electron-quick-start`](https://github.com/atom/electron-quick-start) 저장소를 클론하면 이 문서에서 작성한 예제 앱을 바로 실행해 볼 수 있습니다.
+[`atom/electron-quick-start`](https://github.com/atom/electron-quick-start)
+저장소를 클론하면 이 문서에서 작성한 예제 앱을 바로 실행해 볼 수 있습니다.
-**참고**: 이 예제를 실행시키려면 [Git](https://git-scm.com)과 [Node.js](https://nodejs.org/en/download/)가 필요합니다. (CLI에서 실행 가능한 [npm](https://npmjs.org)이 있어야 합니다)
+**참고**: 이 예제를 실행시키려면 [Git](https://git-scm.com)과
+[Node.js](https://nodejs.org/en/download/)가 필요합니다. (CLI에서 실행 가능한
+ [npm](https://npmjs.org)이 있어야 합니다)
**역주**: `npm`은 보통 Node.js를 설치하면 자동으로 같이 설치됩니다.
$ cd electron-quick-start
# 어플리케이션의 종속성 모듈을 설치한 후 실행합니다
$ npm install && npm start
-```
\ No newline at end of file
+```
### Windows
-Windows 7 이후 버전만 지원됩니다. Windows Vista에서도 작동할 수 있지만 아직 모든 작동 테스트가 완료되지 않았습니다.
+Windows 7 이후 버전만 지원됩니다. Windows Vista에서도 작동할 수 있지만 아직 모든 작동
+테스트가 완료되지 않았습니다.
-윈도우용 바이너리는 `x86`과 `x64` 모두 제공됩니다. 그리고 `ARM` 버전 윈도우는 아직 지원하지 않습니다. (역주: 추후 지원할 가능성이 있습니다)
+윈도우용 바이너리는 `x86`과 `x64` 모두 제공됩니다. 그리고 `ARM` 버전 윈도우는 아직
+지원하지 않습니다. (역주: 추후 지원할 가능성이 있습니다)
### Linux
Ubuntu 12.04 버전에서 빌드된 `ia32`(`i686`), `x64`(`amd64`) 바이너리가 제공됩니다.
-그리고 `arm` 버전 바이너리는 ARM v7 hard-float ABI와 Debian Wheezy용 NEON에 맞춰 제공됩니다.
+그리고 `arm` 버전 바이너리는 ARM v7 hard-float ABI와 Debian Wheezy용 NEON에 맞춰
+제공됩니다.
-미리 빌드된 바이너리가 배포판에서 작동할 수 있는지 여부는 Electron이 빌드된 플랫폼에서 링크된 라이브러리에 따라 달라집니다.
-그래서 현재 Linux 바이너리는 Ubuntu 12.04 버전만 정상적인 작동이 보장됩니다.
-하지만 다음 플랫폼들은 미리 빌드된 Electron 바이너리가 정상적으로 작동하는 것을 확인했습니다:
+미리 빌드된 바이너리가 배포판에서 작동할 수 있는지 여부는 Electron이 빌드된 플랫폼에서
+링크된 라이브러리에 따라 달라집니다. 그래서 현재 Linux 바이너리는 Ubuntu 12.04 버전만
+정상적인 작동이 보장됩니다. 하지만 다음 플랫폼들은 미리 빌드된 Electron 바이너리가
+정상적으로 작동하는 것을 확인했습니다:
* Ubuntu 12.04 이후 버전
* Fedora 21
# 네이티브 node 모듈 사용하기
-Electron에선 node.js 네이티브 모듈이 지원됩니다. 하지만 Electron은 공식 node.js의 V8 엔진과는 다른 V8 버전을 사용합니다.
-이러한 이유로 네이티브 모듈을 사용하기 위해선 Electron의 V8 버전에 맞춰 네이티브 모듈을 다시 빌드하고 헤더를 변경해야 합니다.
+Electron에선 node.js 네이티브 모듈이 지원됩니다. 하지만 Electron은 공식 node.js의
+V8 엔진과는 다른 V8 버전을 사용합니다. 이러한 이유로 네이티브 모듈을 사용하기 위해선
+Electron의 V8 버전에 맞춰 네이티브 모듈을 다시 빌드하고 헤더를 변경해야 합니다.
## 네이티브 node 모듈 호환성
네이티브 모듈은 node.js가 새로운 V8 버전을 사용함으로 인해 작동하지 않을 수 있습니다.
-사용하는 네이티브 모듈이 Electron에 맞춰 작동할 수 있도록 하려면 Electron에서 사용하는 node.js의 버전을 확인할 필요가 있습니다.
-Electron에서 사용하는 node 버전은 [releases](https://github.com/atom/electron/releases)에서 확인할 수 있으며
-`process.version`을 출력하여 버전을 확인할 수도 있습니다. ([시작하기](https://github.com/atom/electron/blob/master/docs/tutorial/quick-start.md)의 예제를 참고하세요)
-
-혹시 직접 만든 네이티브 모듈이 있다면 [NAN](https://github.com/nodejs/nan/) 모듈을 사용하는 것을 고려해보는 것이 좋습니다.
-이 모듈은 다중 버전의 node.js를 지원하기 쉽게 해줍니다. 이를 통해 오래된 모듈을 새 버전의 node.js에 맞게 포팅할 수 있습니다.
+사용하는 네이티브 모듈이 Electron에 맞춰 작동할 수 있도록 하려면 Electron에서 사용하는
+node.js의 버전을 확인할 필요가 있습니다. Electron에서 사용하는 node 버전은
+[releases](https://github.com/atom/electron/releases)에서 확인할 수 있으며
+`process.version`을 출력하여 버전을 확인할 수도 있습니다.
+([시작하기](https://github.com/atom/electron/blob/master/docs/tutorial/quick-start.md)의
+예제를 참고하세요)
+
+혹시 직접 만든 네이티브 모듈이 있다면 [NAN](https://github.com/nodejs/nan/) 모듈을
+사용하는 것을 고려해보는 것이 좋습니다. 이 모듈은 다중 버전의 node.js를 지원하기 쉽게
+만들어 줍니다. 이를 통해 오래된 모듈을 새 버전의 node.js에 맞게 포팅 할 수 있습니다.
Electron도 이 모듈을 통해 포팅된 네이티브 모듈을 사용할 수 있습니다.
## 네이티브 모듈을 설치하는 방법
### 쉬운 방법
-[`electron-rebuild`](https://github.com/paulcbetts/electron-rebuild) 패키지를 사용하면 빠르고 간단하게 네이티브 모듈을 다시 빌드할 수 있습니다.
+[`electron-rebuild`](https://github.com/paulcbetts/electron-rebuild) 패키지를
+사용하면 빠르고 간단하게 네이티브 모듈을 다시 빌드할 수 있습니다.
-다음 예제는 `electron-rebuild`를 통해 자동으로 모듈의 헤더를 다운로드하고 네이티브 모듈을 빌드합니다:
+다음 예제는 `electron-rebuild`를 통해 자동으로 모듈의 헤더를 다운로드하고 네이티브
+모듈을 빌드합니다:
```sh
npm install --save-dev electron-rebuild
### `node-gyp`를 이용한 방법
-Node 모듈을 `node-gyp`를 사용하여 Electron을 타겟으로 빌드할 때는 `node-gyp`에 헤더 다운로드 주소와 버전을 알려주어야 합니다:
+Node 모듈을 `node-gyp`를 사용하여 Electron을 타겟으로 빌드할 때는 `node-gyp`에 헤더
+다운로드 주소와 버전을 알려주어야 합니다:
```bash
$ cd /path-to-module/
$ HOME=~/.electron-gyp node-gyp rebuild --target=0.29.1 --arch=x64 --dist-url=https://atom.io/download/atom-shell
```
-`HOME=~/.electron-gyp`은 변경할 헤더의 위치를 찾습니다. `--target=0.29.1`은 Electron의 버전입니다.
-`--dist-url=...`은 헤더를 다운로드 하는 주소입니다. `--arch=x64`는 64비트 시스템을 타겟으로 빌드 한다는 것을 `node-gyp`에게 알려줍니다.
+`HOME=~/.electron-gyp`은 변경할 헤더의 위치를 찾습니다. `--target=0.29.1`은
+Electron의 버전입니다. `--dist-url=...`은 헤더를 다운로드 하는 주소입니다.
+`--arch=x64`는 64비트 시스템을 타겟으로 빌드 한다는 것을 `node-gyp`에게 알려줍니다.
## 플래시 플러그인 준비하기
-크롬 브라우저의 `chrome://plugins` 페이지에 접속한 후 `세부정보`에서 플래시 플러그인의 위치와 버전을 찾을 수 있습니다.
-Electron에서 플래시 플러그인을 지원하기 위해선 이 두 가지를 복사해 와야 합니다.
+크롬 브라우저의 `chrome://plugins` 페이지에 접속한 후 `세부정보`에서 플래시
+플러그인의 위치와 버전을 찾을 수 있습니다. Electron에서 플래시 플러그인을 지원하기
+위해선 이 두 가지를 복사해 와야 합니다.
## Electron 스위치 추가
-플러그인을 사용하려면 Electron 커맨드 라인에 `--ppapi-flash-path` 와 `ppapi-flash-version` 플래그를 app의 ready 이벤트가 호출되기 전에 추가해야 합니다.
+플러그인을 사용하려면 Electron 커맨드 라인에 `--ppapi-flash-path` 와
+`ppapi-flash-version` 플래그를 app의 ready 이벤트가 호출되기 전에 추가해야 합니다.
그리고 `browser-window`에 `plugins` 스위치도 추가해야합니다.
```javascript
[ChromeDriver - WebDriver for Chrome][chrome-driver]로 부터 인용:
> WebDriver는 많은 브라우저에서 웹 앱을 자동적으로 테스트하는 툴입니다.
-> 이 툴킷은 웹 페이지를 자동으로 탐색하고 유저 폼을 사용하거나 자바스크립트를 실행하는 등의 작업을 수행할 수 있습니다.
-> ChromeDriver는 Chromium의 WebDriver wire 프로토콜 스텐드얼론 서버 구현입니다.
-> Chromium 과 WebDriver 팀 멤버에 의해 개발되었습니다.
+> 이 툴킷은 웹 페이지를 자동으로 탐색하고 유저 폼을 사용하거나 자바스크립트를 실행하는
+> 등의 작업을 수행할 수 있습니다. ChromeDriver는 Chromium의 WebDriver wire 프로토콜
+> 스텐드얼론 서버 구현입니다. Chromium 과 WebDriver 팀 멤버에 의해 개발되었습니다.
-Electron에서 `chromedriver`를 사옹하려면 드라이버에서 Electron을 찾을 수 있도록 해야 하며
-Electron은 Chrome 브라우저와 비슷하다는 점을 기억해야 합니다.
+Electron에서 `chromedriver`를 사옹하려면 드라이버에서 Electron을 찾을 수 있도록 해야
+하며 Electron은 Chrome 브라우저와 비슷하다는 점을 기억해야 합니다.
## WebDriverJs 설정하기
-[WebDriverJs](https://code.google.com/p/selenium/wiki/WebDriverJs)는 WebDriver를 사용하여 테스트 할 수 있도록 도와주는 node 패키지입니다.
-다음 예제를 참고하세요.
+[WebDriverJs](https://code.google.com/p/selenium/wiki/WebDriverJs)는 WebDriver를
+사용하여 테스트 할 수 있도록 도와주는 node 패키지입니다. 다음 예제를 참고하세요.
### 1. 크롬 드라이버 시작
### 3. 크롬 드라이버에 연결
-`selenium-webdriver`를 Electron과 같이 사용하는 방법은 기본적으로 upstream과 같습니다.
-한가지 다른점이 있다면 수동으로 크롬 드라이버 연결에 대해 설정하고 Electron 실행파일의 위치를 전달합니다:
+`selenium-webdriver`를 Electron과 같이 사용하는 방법은 기본적으로 upstream과
+같습니다. 한가지 다른점이 있다면 수동으로 크롬 드라이버 연결에 대해 설정하고 Electron
+실행파일의 위치를 전달합니다:
```javascript
const webdriver = require('selenium-webdriver');
## WebdriverIO 설정하기
-[WebdriverIO](http://webdriver.io/)는 웹 드라이버와 함께 테스트를 위해 제공되는 node 패키지입니다.
+[WebdriverIO](http://webdriver.io/)는 웹 드라이버와 함께 테스트를 위해 제공되는
+node 패키지입니다.
### 1. 크롬 드라이버 시작
};
var client = webdriverio.remote(options);
-
+
client
.init()
.url('http://google.com')
## 작업 환경
-따로 Electron을 다시 빌드하지 않는 경우 간단히 어플리케이션을 Electron의 리소스 디렉터리에
-[배치](application-distribution.md)하여 바로 테스트 할 수 있습니다.
+따로 Electron을 다시 빌드하지 않는 경우 간단히 어플리케이션을 Electron의 리소스
+디렉터리에 [배치](application-distribution.md)하여 바로 테스트 할 수 있습니다.
-또한, Electron 바이너리의 명령줄 인수에 어플리케이션 폴더를 지정하는 방법으로 실행할 수도 있습니다.
-이 방법을 사용하면 어플리케이션 폴더를 Electron의 `resource` 디렉터리로 복사하는 불필요한 과정을 생략할 수 있습니다.
+또한, Electron 바이너리의 명령줄 인수에 어플리케이션 폴더를 지정하는 방법으로 실행할
+수도 있습니다. 이 방법을 사용하면 어플리케이션 폴더를 Electron의 `resource`
+디렉터리로 복사하는 불필요한 과정을 생략할 수 있습니다.
[chrome-driver]: https://sites.google.com/a/chromium.org/chromedriver/
projects / platform / framework / web / crosswalk-tizen.git / commitdiff