mirrors/electron
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions 1

Fix typos, add more files

Browse source
This commit is contained in:
Plusb Preco 2015-06-26 02:32:51 +09:00
parent bf5b084945
commit ebb031dafe
45 changed files with 3450 additions and 239 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/tutorial/application-distribution-ko.md
View file

@ -23,12 +23,12 @@ electron/resources/app
└── index.html
```
그리고 `Electron.app`을 실행하면 (Linux에선 `electron` Windows에선 `electron.exe`입니다), Electron은 해당 앱을 실행시킵니다.
그리고 `Electron.app`을 실행하면(Linux에선 `electron` Windows에선 `electron.exe`입니다) Electron은 해당 앱을 실행시킵니다.
최종 사용자에게는 이 `electron` 폴더(Electron.app)를 배포하면 됩니다.
## asar로 앱 패키징 하기
소스파일 전체를 복사해서 배포하는 것과는 별개로, [asar](https://github.com/atom/asar) 아카이브를 통해
소스파일 전체를 복사해서 배포하는 것과는 별개로 [asar](https://github.com/atom/asar) 아카이브를 통해
어플리케이션의 소스코드가 사용자에게 노출되는 것을 방지할 수 있습니다.
`asar` 아카이브를 사용할 땐 단순히 `app` 폴더 대신에 어플리케이션을 패키징한 `app.asar` 파일로 대체하면됩니다.
@ -52,7 +52,7 @@ electron/resources/
## 다운로드한 바이너리의 리소스를 앱에 맞게 수정하기
어플리케이션을 Electron에 번들링한 후, 해당 어플리케이션에 맞게 리브랜딩 할 수 있습니다.
어플리케이션을 Electron에 번들링한 후 해당 어플리케이션에 맞게 리브랜딩 할 수 있습니다.
### Windows

36
docs/tutorial/application-packaging-ko.md
View file

@ -1,6 +1,6 @@
# 어플리케이션 패키징
어플리케이션의 리소스와 소스코드를 유저로부터 보호하기 위해, 약간의 구조 변경으로 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
어플리케이션의 리소스와 소스코드를 유저로부터 보호하기 위해 약간의 구조 변경으로 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
## `asar` 아카이브 생성
@ -23,7 +23,7 @@ $ asar pack your-app app.asar
## `asar` 아카이브 사용하기
Electron은 두가지의 API를 가지고 있습니다: Node.js로 부터 제공된 Node API, Chromium으로부터 제공된 Web API.
Electron은 Node.js로 부터 제공된 Node API와 Chromium으로부터 제공된 Web API 두가지의 API를 가지고 있습니다.
두 API 모두 `asar`에서 읽어들일 수 있도록 지원합니다.
### Node API
@ -31,7 +31,7 @@ Electron은 두가지의 API를 가지고 있습니다: Node.js로 부터 제공
`fs.readFile` 와 `require` 같은 Node API들을 지원하기 위해 Electron에선 `asar` 아카이브가 가상의 디렉터리 구조를 가지도록
패치했습니다. 그래서 아카이브 내부에서 리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다.
예를들어, `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면:
예를들어 `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면:
```bash
$ asar list /path/to/example.asar
@ -73,10 +73,10 @@ win.loadUrl('file:///path/to/example.asar/static/index.html');
### Web API
웹 페이지 내에선, 아카이브 내의 파일을 `file:` 프로토콜을 사용하여 요청할 수 있습니다.
웹 페이지 내에선 아카이브 내의 파일을 `file:` 프로토콜을 사용하여 요청할 수 있습니다.
이 또한 Node API와 같이 가상 디렉터리 구조를 가집니다.
예를들어, jQuery의 `$.get`을 사용하여 파일을 가져올 수 있습니다:
예를들어 jQuery의 `$.get`을 사용하여 파일을 가져올 수 있습니다:
```html
<script>
@ -89,7 +89,7 @@ $.get('file:///path/to/example.asar/file.txt', function(data) {
### `asar` 아카이브를 일반 파일로 취급하기
`asar` 아카이브의 체크섬(checksum)등을 검사하기 위해선, `asar` 아카이브를 파일 그대로 읽어들여야 할 필요가 있습니다.
`asar` 아카이브의 체크섬(checksum)등을 검사하기 위해선 `asar` 아카이브를 파일 그대로 읽어들여야 할 필요가 있습니다.
이 작업을 하기 위해 `original-fs`라고 하는 빌트인 모듈을 `fs` 모듈 대신에 사용할 수 있습니다.
이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를 읽어들입니다:
@ -100,24 +100,20 @@ originalFs.readFileSync('/path/to/example.asar');
## Node API의 한계
`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만, 여전히 저수준(low-level) Node API 때문에 한계가 있습니다.
Even though we tried hard to make `asar` archives in the Node API work like
directories as much as possible, there are still limitations due to the
low-level nature of the Node API.
`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만 여전히 저수준(low-level nature) Node API 때문에 한계가 있습니다.
### 아카이브는 읽기 전용입니다
아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만, `asar` 아카이브에선 작동하지 않습니다.
아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만 `asar` 아카이브에선 작동하지 않습니다.
### 아카이브 안의 디렉터리를 작업 경로로 설정하면 안됩니다
`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만, 그것은 실제 파일시스템의 디렉터리가 아닌 가상의 디렉터리입니다.
`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만 그것은 실제 파일시스템의 디렉터리가 아닌 가상의 디렉터리입니다.
그런 이유로 몇몇 API에서 지원하는 `cwd` 옵션을 `asar` 아카이브 안의 디렉터리 경로로 지정하면 나중에 문제가 발생할 수 있습니다.
### 특정 API로 인한 예외적인 압축 해제
많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를 가져올 수 있으나,
많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를 가져올 수 있으나
몇몇 API는 시스템의 실제 파일의 경로를 기반으로 작동하므로 이 API들을 사용할 땐 Electron은
이 API가 원할하게 작동할 수 있도록 하기 위해 임시경로에 해당 파일들의 압축을 해제합니다. 이 작업은 약간의 오버헤드를 불러 일으킬 수 있습니다.
@ -128,25 +124,25 @@ low-level nature of the Node API.
* `fs.openSync`
* `process.dlopen` - Used by `require` on native modules
### `fs.stat`의 잘못된 스테이터스
### `fs.stat`의 잘못된 스테이터스 정보
`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 가상의 예측된 정보를 가집니다.
`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 예측된 디렉터리 피일 정보를 가집니다.
왜냐하면 아카이브의 디렉터리 경로는 실제 파일시스템에 존재하지 않기 때문입니다.
그러한 이유로 파일 크기와 파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다.
## Adding unpacked files in `asar` archive
## `asar` 아카이브에 미리 압축 해제된 파일 추가하기
전술한 바와 같이, 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다.
전술한 바와 같이 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다.
따로 성능문제가 발생할 수 있습니다. 그리고 백신 소프트웨어의 잘못된 오진을 일으킬 수도 있습니다.
이 문제를 해결하려면, `--unpack` 옵션을 활용하여 파일을 압축이 풀려진 상태로 유지해야 합니다.
이 문제를 해결하려면 `--unpack` 옵션을 활용하여 파일을 압축이 풀려진 상태로 유지해야 합니다.
다음의 예제는 node 네이티브 모듈의 공유 라이브러리를 unpack 상태로 유지합니다:
```bash
$ asar pack app app.asar --unpack *.node
```
커맨드를 실행한 후, 같은 디렉터리에 `app.asar` 파일 외에 `app.asar.unpacked` 폴더가 같이 생성됩니다.
커맨드를 실행한 후 같은 디렉터리에 `app.asar` 파일 외에 `app.asar.unpacked` 폴더가 같이 생성됩니다.
이 폴더안에 unpack 옵션에서 설정한 파일들이 압축이 풀린 상태로 포함되어 있습니다.
유저에게 어플리케이션을 배포할 때 반드시 해당 폴더도 같이 배포하여야합니다.

4
docs/tutorial/debugging-main-process-ko.md
View file

@ -1,7 +1,7 @@
# 메인 프로세스 디버깅하기
브라우저 창의 개발자 콘솔은 랜더러 프로세스의 스크립트만 디버깅이 가능합니다. (다시말해 웹 페이지)
메인 프로세스의 디버깅 방법을 제공하기 위해, Electron은 `--debug` 과 `--debug-brk` 스위치들을 제공합니다.
메인 프로세스의 디버깅 방법을 제공하기 위해 Electron은 `--debug` 과 `--debug-brk` 스위치들을 제공합니다.
## 커맨드 라인 스위치(command line switches)
@ -15,7 +15,7 @@
## node-inspector로 디버깅 하기
__주의:__ Electron은 node v0.11.13 버전을 사용합니다, node-inspector는 현재 아주 잘 작동하지 않습니다.
__주의:__ Electron은 node v0.11.13 버전을 사용합니다. node-inspector는 현재 아주 잘 작동하지 않습니다.
그리고 메인 프로세스의 `process`를 node-inspector 콘솔 내에서 검사할 경우 크래시가 발생할 수 있습니다.
### 1. [node-inspector][node-inspector] 서버 시작

30
docs/tutorial/desktop-environment-integration-ko.md
View file

@ -1,7 +1,7 @@
# 데스크톱 환경 통합
# 데스크톱 환경 통합
어플리케이션을 배포할 서로 다른 운영체제 시스템의 환경과 기능에 맞춰 사용 환경을 통합할 수 있습니다.
예를 들어, Windows에선 태스크바의 JumpList에 바로가기를 추가할 수 있고, Mac(OS X)에선 dock menu에 커스텀 메뉴를 추가할 수 있습니다.
예를 들어 Windows에선 태스크바의 JumpList에 바로가기를 추가할 수 있고 Mac(OS X)에선 dock menu에 커스텀 메뉴를 추가할 수 있습니다.
이 가이드는 Electron API를 이용하여 각 운영체제 시스템의 기능을 활용하는 방법을 설명합니다.
@ -17,7 +17,7 @@ __어플리케이션 dock menu:__
<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
var app = require('app');
@ -32,15 +32,15 @@ app.clearRecentDocuments();
### Windows에서 주의할 점
이 기능을 Windows에서 사용할 땐, 운영체제 시스템에 어플리케이션에서 사용하는 파일 확장자가 등록되어 있어야 합니다.
이 기능을 Windows에서 사용할 땐 운영체제 시스템에 어플리케이션에서 사용하는 파일 확장자가 등록되어 있어야 합니다.
그렇지 않은 경우 파일을 JumpList에 추가해도 추가되지 않습니다.
어플리케이션 등록에 관련된 API의 모든 내용은 [Application Registration][app-registration]에서 찾아볼 수 있습니다.
유저가 JumpList에서 파일을 클릭할 경우, 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어 새로운 인스턴스의 어플리케이션이 실행됩니다.
유저가 JumpList에서 파일을 클릭할 경우 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어 새로운 인스턴스의 어플리케이션이 실행됩니다.
### OS X에서 주의할 점
파일이 최근 문서 메뉴에서 요청될 경우, `app` 모듈의 `open-file` 이벤트가 호출됩니다.
파일이 최근 문서 메뉴에서 요청될 경우 `app` 모듈의 `open-file` 이벤트가 호출됩니다.
## 커스텀 독 메뉴 (OS X)
@ -51,7 +51,7 @@ __Terminal.app의 dock menu:__
<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
var app = require('app');
@ -74,7 +74,7 @@ MSDN에선 해당 기능을 다음과 같이 설명하고 있습니다:
> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을 예측하여 정의합니다.
> 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시 context-free를 유지해야 합니다.
> 작업은 일반 사용자가 프로그램을 실행하거나, 이메일 프로그램으로 이메일을 작성하거나 달력을 불러오고,
> 작업은 일반 사용자가 프로그램을 실행하거나 이메일 프로그램으로 이메일을 작성하거나 달력을 불러오고
> 워드 프로세서로 새 문서를 작성, 특정 모드, 부속 명령으로 프로그램을 실행하는 등의
> 통계적, 일반적으로 가장 많이 사용되는 작업인지를 고려해야 합니다.
> 어플리케이션 작업은 일반 유저가 필요로 하지 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다.
@ -82,14 +82,14 @@ MSDN에선 해당 기능을 다음과 같이 설명하고 있습니다:
>
> 작업 리스트는 가능한 한 정적으로 유지되는 것을 적극 권장합니다.
> 이것은 동일한 상태 또는 응용 프로그램의 상태에 관계없이 유지되어야 합니다.
> 작업 목록은 동적으로 변경할 수 있지만, 몇몇 유저는 예상하지 못한 작업 목록 변경에 혼동할 수 있다는 점을 고려해야 합니다.
> 작업 목록은 동적으로 변경할 수 있지만 몇몇 유저는 예상하지 못한 작업 목록 변경에 혼동할 수 있다는 점을 고려해야 합니다.
__Internet Explorer의 작업:__
![IE](http://i.msdn.microsoft.com/dynimg/IC420539.png)
OS X의 말 그대로 메뉴로 작동하는 dock menu 와는 달리, Windows의 사용자 작업은 어플리케이션 바로가기처럼 작동합니다.
유저가 작업을 클릭할 시, 설정한 인자와 함께 새로운 어플리케이션이 실행됩니다.
OS X의 말 그대로 메뉴로 작동하는 dock menu 와는 달리 Windows의 사용자 작업은 어플리케이션 바로가기처럼 작동합니다.
유저가 작업을 클릭할 시 설정한 인자와 함께 새로운 어플리케이션이 실행됩니다.
사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] API를 사용하여 구현할 수 있습니다:
@ -107,7 +107,7 @@ app.setUserTasks([
]);
```
작업 리스트를 비우려면, 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어 호출하면 됩니다:
작업 리스트를 비우려면 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어 호출하면 됩니다:
```javascript
app.setUserTasks([]);
@ -117,7 +117,7 @@ app.setUserTasks([]);
## Unity 런처 숏컷 기능 (Linux)
Unity 환경에선, `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding shortcuts to a launcher][unity-launcher] 가이드를 참고하세요.
Unity 환경에선 `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding shortcuts to a launcher][unity-launcher] 가이드를 참고하세요.
__Audacious의 런처 숏컷:__
@ -147,8 +147,8 @@ window.setProgressBar(0.5);
## 윈도우 대표 파일 제시 (OS X)
OS X는 윈도우에서 대표 파일을 설정할 수 있습니다. 쉽게 말해, 타이틀바에서 파일 아이콘을 볼 수 있을 때, 사용자가 Command-Click 또는 Control-Click 할 경우 파일 경로 팝업이 보여집니다.
또한 윈도우의 상태도 지정할 수 있습니다. 쉽게 말해, 로드된 문서의 수정여부를 타이틀바 파일 아이콘에 표시할 수 있습니다.
OS X는 윈도우에서 대표 파일을 설정할 수 있습니다. 쉽게 말해 타이틀바에서 파일 아이콘을 볼 수 있을 때 사용자가 Command-Click 또는 Control-Click 할 경우 파일 경로 팝업이 보여집니다.
또한 윈도우의 상태도 지정할 수 있습니다. 쉽게 말해 로드된 문서의 수정여부를 타이틀바 파일 아이콘에 표시할 수 있습니다.
__대표 파일 팝업 메뉴:__

11
docs/tutorial/devtools-extension-ko.md
View file

@ -1,11 +1,11 @@
# 개발자 콘솔 확장
어플리케이션의 디버깅을 쉽게 하기 위해, Electron은 기본적으로 [Chrome DevTools Extension][devtools-extension]을 지원합니다.
어플리케이션의 디버깅을 쉽게 하기 위해 Electron은 기본적으로 [Chrome DevTools Extension][devtools-extension]을 지원합니다.
개발자 콘솔 확장기능은 간단하게 사용할 확장기능 플러그인의 소스코드를 다운로드한 후 `BrowserWindow.addDevToolsExtension` API를 이용하여
어플리케이션 내에 로드할 수 있습니다. 한가지 주의할 점은 확장기능 사용시 창이 생성될 때 마다 일일이 해당 API를 호출할 필요는 없습니다.
예시로 [React DevTools Extension](https://github.com/facebook/react-devtools)을 사용하자면, 먼저 소스코드를 다운로드 받아야합니다:
예시로 [React DevTools Extension](https://github.com/facebook/react-devtools)을 사용 한다면 먼저 소스코드를 다운로드 받고:
```bash
$ cd /some-directory
@ -18,7 +18,7 @@ $ git clone --recursive https://github.com/facebook/react-devtools.git
require('remote').require('browser-window').addDevToolsExtension('/some-directory/react-devtools');
```
확장기능을 unload 하려면, `BrowserWindow.removeDevToolsExtension` API를 사용하여 다음에 콘솔을 다시 열 때 해당 확장기능이 로드되지 않도록 할 수 있습니다:
확장기능을 unload 하려면 `BrowserWindow.removeDevToolsExtension` API를 사용하여 다음에 콘솔을 다시 열 때 해당 확장기능이 로드되지 않도록 할 수 있습니다:
```javascript
require('remote').require('browser-window').removeDevToolsExtension('React Developer Tools');
@ -33,12 +33,11 @@ require('remote').require('browser-window').removeDevToolsExtension('React Devel
## 백그라운드 페이지
현재 Electron은 Chrome에서 지원하는 백그라운드 페이지(background pages)를 지원하지 않습니다.
몇몇 확장기능은 이 기능에 의존하는 경우가 있는데, 이 경우 해당 확장기능은 Electron에서 작동하지 않을 수 있습니다.
몇몇 확장기능은 이 기능에 의존하는 경우가 있는데 이 경우 해당 확장기능은 Electron에서 작동하지 않을 수 있습니다.
## `chrome.*` API
몇몇 Chrome 확장기능은 특정 기능을 사용하기 위해 `chrome.*` API를 사용하는데, Electron에선 이 API들을 구현하기 위해 노력했지만,
안타깝게도 아직 모든 API가 구현되지는 않았습니다.
몇몇 Chrome 확장기능은 특정 기능을 사용하기 위해 `chrome.*` API를 사용하는데, Electron에선 이 API들을 구현하기 위해 노력했지만 안타깝게도 아직 모든 API가 구현되지는 않았습니다.
아직 모든 API가 구현되지 않았기 때문에 확장기능에서 `chrome.devtools.*` 대신 `chrome.*` API를 사용할 경우 확장기능이 제대로 작동하지 않을 수 있음을 감안해야 합니다.
만약 문제가 발생할 경우 Electron의 GitHub repo에 이슈를 올리면 해당 API를 추가하는데 많은 도움이 됩니다.

2
docs/tutorial/online-offline-events-ko.md
View file

@ -35,7 +35,7 @@ _online-status.html_
</html>
```
필요하다면, 이러한 이벤트를 메인 프로세스로 보낼 수도 있습니다.
필요한 경우 이 이벤트를 메인 프로세스로 보낼 수도 있습니다.
메인 프로세스는 `navigator` 오브젝트를 가지고 있지 않기 때문에 이 이벤트를 직접 사용할 수 없습니다.
이는 다음 예제와 같이 electron의 inter-process communication(ipc)유틸리티를 사용하여
이벤트를 메인 프로세스로 전달하는 것으로 해결할 수 있습니다.

32
docs/tutorial/quick-start-ko.md
View file

@ -12,34 +12,34 @@ Electron은 자바스크립트와 함께 제공되는 풍부한 네이티브 API
### 메인 프로세스
Electron은 실행될 때 __메인 프로세스__ 로 불리는 `package.json`의 `main` 스크립트를 호출합니다.
이 스크립트는 메인 프로세스에서 작동합니다, GUI 컴포넌트를 컨트롤하거나 웹 페이지 창을 생성할 수 있습니다.
이 스크립트는 메인 프로세스에서 작동합니다. GUI 컴포넌트를 컨트롤하거나 웹 페이지 창을 생성할 수 있습니다.
### 랜더러 프로세스
Electron이 웹페이지를 보여줄 때, Chromium의 multi-processes 구조도 같이 사용됩니다.
Electron이 웹페이지를 보여줄 때 Chromium의 multi-processes 구조도 같이 사용됩니다.
Electron 프로세스 내에서 작동하는 웹 페이지는 __랜더러 프로세스__ 라고 불립니다.
보통, 일반 브라우저의 웹 페이지들은 샌드박스가 적용된 환경에서 작동하며 네이티브 리소스에는 접근할 수 없도록 되어 있습니다.
보통 일반 브라우저의 웹 페이지들은 샌드박스가 적용된 환경에서 작동하며 네이티브 리소스에는 접근할 수 없도록 되어 있습니다.
하지만 Electron은 웹 페이지 내에서 io.js(node.js) API를 사용하여 low-level 수준으로 운영체제와 상호작용할 수 있습니다.
### 메인 프로세스와 랜더러 프로세스의 차이점
메인 프로세스는 `BrowserWindow` Class를 이용하여 창을 만들 수 있습니다. `BrowserWindow` 인스턴스는
따로 분리된 프로세스에서 랜더링 되며, `BrowserWindow` 인스턴스가 소멸할 때, 해당하는 랜더러 프로세스도 같이 소멸합니다.
따로 분리된 프로세스에서 랜더링 되며 `BrowserWindow` 인스턴스가 소멸할 때 해당하는 랜더러 프로세스도 같이 소멸합니다.
메인 프로세스는 모든 웹 페이지와 그에 해당하는 랜더러 프로세스를 관리하며,
메인 프로세스는 모든 웹 페이지와 그에 해당하는 랜더러 프로세스를 관리하며
랜더러 프로세스는 각각의 프로세스에 고립되며 웹 페이지의 작동에만 영향을 끼칩니다.
웹 페이지 내에서 네이티브 GUI 리소스를 관리하는 것은 매우 위험하고,
리소스를 누수시킬 수 있기 때문에 웹 페이지 내에서는 네이티브 GUI와 관련된 API를 호출할 수 없도록 되어 있습니다.
만약 웹 페이지 내에서 GUI작업이 필요하다면, 메인 프로세스에서 그 작업을 할 수 있도록 통신을 해야합니다.
웹 페이지 내에서 네이티브 GUI 리소스를 관리하는 것은 보안에 취약하고 리소스를 누수시킬 수 있기 때문에
웹 페이지 내에서는 네이티브 GUI와 관련된 API를 호출할 수 없도록 되어 있습니다.
만약 웹 페이지 내에서 GUI작업이 필요하다면 메인 프로세스에서 그 작업을 할 수 있도록 메인 프로세스와 통신을 해야합니다.
Electron에는 메인 프로세스와 랜더러 프로세스간에 통신을 할 수 있도록 [ipc](../api/ipc-renderer-ko.md) 모듈을 제공하고 있습니다.
또한 [remote](../api/remote-ko.md) 모듈을 사용하여 RPC 스타일로 통신할 수도 있습니다.
## 나의 첫번째 Electron 앱 만들기
보통, Electron 앱은 다음과 같은 폴더 구조를 가집니다:
보통 Electron 앱은 다음과 같은 폴더 구조를 가집니다:
```text
your-app/
@ -48,7 +48,7 @@ your-app/
└── index.html
```
`package.json`은 node 모듈의 package.json과 같습니다, 그리고 `main` 필드를 지정하여
`package.json`은 node 모듈의 package.json과 같습니다. 그리고 `main` 필드를 지정하여
메인 프로세스로 사용할 어플리케이션 시작점을 정의할 수 있습니다.
예를 들어 사용할 수 있는 `package.json`은 다음과 같습니다:
@ -60,7 +60,7 @@ your-app/
}
```
`main.js`에서 창을 만들거나 시스템 이벤트를 처리할 수 있습니다, 대표적인 예제로 다음과 같이 작성할 수 있습니다:
`main.js`에서 창을 만들거나 시스템 이벤트를 처리할 수 있습니다. 대표적인 예제로 다음과 같이 작성할 수 있습니다:
```javascript
var app = require('app'); // 어플리케이션 기반을 조작 하는 모듈.
@ -69,7 +69,7 @@ var BrowserWindow = require('browser-window'); // 네이티브 브라우저 창
// Electron 개발자에게 crash-report를 보냄.
require('crash-reporter').start();
// 윈도우 객체를 전역에 유지합니다, 만약 이렇게 하지 않으면,
// 윈도우 객체를 전역에 유지합니다. 만약 이렇게 하지 않으면
// 자바스크립트 GC가 일어날 때 창이 자동으로 닫혀버립니다.
var mainWindow = null;
@ -94,15 +94,15 @@ app.on('ready', function() {
// 창이 닫히면 호출됩니다.
mainWindow.on('closed', function() {
// 윈도우 객체의 참조를 삭제합니다, 보통 멀티 윈도우 지원을 위해
// 윈도우 객체를 배열에 저장하는 경우가 있는데, 이 경우
// 윈도우 객체의 참조를 삭제합니다 보통 멀티 윈도우 지원을 위해
// 윈도우 객체를 배열에 저장하는 경우가 있는데 이 경우
// 해당하는 모든 윈도우 객체의 참조를 삭제해 주어야 합니다.
mainWindow = null;
});
});
```
마지막으로, 사용자에게 보여줄 `index.html` 웹 페이지의 예제입니다:
마지막으로 사용자에게 보여줄 `index.html` 웹 페이지의 예제입니다:
```html
<!DOCTYPE html>
@ -120,7 +120,7 @@ app.on('ready', function() {
## 앱 실행하기
앱을 작성한 후, [어플리케이션 배포](./application-distribution-ko.md) 가이드를 따라 앱을 패키징 하고
앱을 작성한 후 [어플리케이션 배포](./application-distribution-ko.md) 가이드를 따라 앱을 패키징 하고
패키징한 앱을 실행해 볼 수 있습니다. 또한 Electron 실행파일을 다운로드 받아 바로 실행해 볼 수도 있습니다.
Windows의 경우:

8
docs/tutorial/using-native-node-modules-ko.md
View file

@ -10,10 +10,10 @@ Electron에선 node.js 네이티브 모듈이 지원됩니다. 하지만 Electro
Node v0.11.x 버전부터는 V8 API의 중대한 변경이 있었습니다. 하지만 일반적으로 모든 네이티브 모듈은 Node v0.10.x 버전을 타겟으로 작성 되었기 때문에
Node v0.11.x 버전에선 작동하지 않습니다. Electron은 내부적으로 Node v0.11.13 버전을 사용합니다. 그래서 위에서 설명한 문제가 발생합니다.
이 문제를 해결하기 위해, 모듈이 Node v0.11.x 버전을 지원할 수 있도록 해야합니다.
현재 [많은 모듈들](https://www.npmjs.org/browse/depended/nan)이 안정적으로 두 버전 모두 지원하고 있지만,
이 문제를 해결하기 위해 모듈이 Node v0.11.x 버전을 지원할 수 있도록 해야합니다.
현재 [많은 모듈들](https://www.npmjs.org/browse/depended/nan)이 안정적으로 두 버전 모두 지원하고 있지만
오래된 모듈의 경우 Node v0.10.x 버전만을 지원하고 있습니다.
예를들어 [nan](https://github.com/rvagg/nan) 모듈을 사용해야 하는 경우, Node v0.11.x 버전으로 포팅 할 필요가 있습니다.
예를들어 [nan](https://github.com/rvagg/nan) 모듈을 사용해야 하는 경우 Node v0.11.x 버전으로 포팅 할 필요가 있습니다.
## 네이티브 모듈 설치하는 방법
@ -31,7 +31,7 @@ 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/

2
docs/tutorial/using-pepper-flash-plugin-ko.md
View file

@ -1,6 +1,6 @@
# Pepper 플래시 플러그인 사용하기
필요하다면 Pepper 플래시 플러그인을 사용할 수 있습니다. Electron에서 pepper 플래시 플러그인을 사용하기 위해서는, 따로 pepper 플래시 플러그인의 위치를 지정해 주어야합니다.
필요하다면 Pepper 플래시 플러그인을 사용할 수 있습니다. Electron에서 pepper 플래시 플러그인을 사용하기 위해선 따로 pepper 플래시 플러그인의 위치를 지정해 주어야합니다.
## 플래시 플러그인 준비하기

10
docs/tutorial/using-selenium-and-webdriver-ko.md
View file

@ -3,13 +3,13 @@
[ChromeDriver - WebDriver for Chrome][chrome-driver]로 부터 인용:
> WebDriver는 많은 브라우저에서 웹 앱을 자동적으로 테스트하는 툴입니다.
> 이 툴킷은 웹 페이지를 자동으로 탐색하고, 유저 폼을 사용하거나, 자바스크립트를 실행하는 등의 작업을 수행할 수 있습니다.
> 이 툴킷은 웹 페이지를 자동으로 탐색하고 유저 폼을 사용하거나 자바스크립트를 실행하는 등의 작업을 수행할 수 있습니다.
> ChromeDriver는 Chromium의 WebDriver wire 프로토콜 스텐드얼론 서버 구현입니다.
> Chromium 과 WebDriver 팀 멤버에 의해 개발되었습니다.
Electron의 [releases](https://github.com/atom/electron/releases) 페이지에서 `chromedriver` 릴리즈 압축파일을 찾을 수 있습니다.
`chromedriver`의 Electron 배포판과 upstream과의 차이는 없습니다.
`chromedriver`와 Electron을 함께 사용하려면, 몇가지 설정이 필요합니다.
`chromedriver`와 Electron을 함께 사용하려면 몇가지 설정이 필요합니다.
또한 releases에는 `chromedriver`를 포함하여 주 버전만 업데이트 됩니다. (예시: `vX.X.0` releases)
왜냐하면 `chromedriver`는 Electron 자체에서 자주 업데이트하지 않기 때문입니다.
@ -29,7 +29,7 @@ Starting ChromeDriver (v2.10.291558) on port 9515
Only local connections are allowed.
```
포트 `9515`를 기억하세요, 나중에 사용합니다
곧 사용하므로 포트 `9515`를 기억해 놓습니다.
### 2. WebDriverJS 설치
@ -40,7 +40,7 @@ $ npm install selenium-webdriver
### 3. 크롬 드라이버에 연결
`selenium-webdriver`를 Electron과 같이 사용할 땐 기본적으로 upstream과 같습니다.
한가지 다른점이 있다면 수동으로 크롬 드라이버 연결에 대해 설정하고 , Electron 실행파일의 위치를 전달합니다:
한가지 다른점이 있다면 수동으로 크롬 드라이버 연결에 대해 설정하고 Electron 실행파일의 위치를 전달합니다:
```javascript
var webdriver = require('selenium-webdriver');
@ -68,7 +68,7 @@ driver.quit();
## 작업환경
따로 Electron을 다시 빌드하지 않는다면, 간단히 어플리케이션을 Electron의 리소스 디렉터리에
따로 Electron을 다시 빌드하지 않는 경우 간단히 어플리케이션을 Electron의 리소스 디렉터리에
[배치](https://github.com/atom/electron/blob/master/docs/tutorial/application-distribution-ko.md)하여 바로 테스트 할 수 있습니다.
[chrome-driver]: https://sites.google.com/a/chromium.org/chromedriver/