From ae8ffae59ee32dc1360c238e99dfb0cdd44e991d Mon Sep 17 00:00:00 2001 From: Plusb Preco Date: Fri, 4 Sep 2015 16:01:43 +0900 Subject: [PATCH] Improve grammar, update as upstream --- README-ko.md | 2 +- docs-translations/ko/api/content-tracing.md | 14 +- docs-translations/ko/api/menu.md | 2 +- docs-translations/ko/api/web-frame.md | 27 +- docs-translations/ko/api/web-view-tag.md | 243 ++++++++++-------- docs-translations/ko/api/window-open.md | 22 +- .../development/atom-shell-vs-node-webkit.md | 7 +- .../development/build-instructions-linux.md | 12 +- ...tions-mac.md => build-instructions-osx.md} | 10 +- .../development/build-instructions-windows.md | 43 ++-- .../ko/development/build-system-overview.md | 12 +- .../ko/development/coding-style.md | 15 +- .../source-code-directory-structure.md | 65 ++--- .../ko/tutorial/application-distribution.md | 8 +- .../ko/tutorial/application-packaging.md | 8 +- .../ko/tutorial/debugging-main-process.md | 13 +- .../desktop-environment-integration.md | 10 +- .../ko/tutorial/devtools-extension.md | 24 +- .../ko/tutorial/online-offline-events.md | 4 +- docs-translations/ko/tutorial/quick-start.md | 17 +- .../ko/tutorial/using-native-node-modules.md | 6 +- .../ko/tutorial/using-pepper-flash-plugin.md | 10 +- .../tutorial/using-selenium-and-webdriver.md | 18 +- 23 files changed, 325 insertions(+), 267 deletions(-) rename docs-translations/ko/development/{build-instructions-mac.md => build-instructions-osx.md} (76%) diff --git a/README-ko.md b/README-ko.md index 1b895c159798..9e8b8e5a8673 100644 --- a/README-ko.md +++ b/README-ko.md @@ -6,7 +6,7 @@ ### [Electron](https://github.com/atom/electron/) 한국어 참조문서 -:zap: *프레임워크 이름이 Atom Shell에서 Electron으로 바뀌었습니다* :zap: +:zap: *프레임워크 이름이 Atom Shell에서 Electron으로 변경되었습니다* :zap: Electron 프레임워크는 JavaScript, HTML 그리고 CSS를 사용하여 Cross-Platform 데스크톱 어플리케이션을 개발할 수 있도록 해주는 프레임워크입니다. 이 프레임워크는 [io.js](http://iojs.org) 와 [Chromium](http://www.chromium.org)을 기반으로 만들어 졌으며 [Atom Editor](https://github.com/atom/atom)에 사용되고 있습니다. diff --git a/docs-translations/ko/api/content-tracing.md b/docs-translations/ko/api/content-tracing.md index f6010d156f6a..79c1d82b269a 100644 --- a/docs-translations/ko/api/content-tracing.md +++ b/docs-translations/ko/api/content-tracing.md @@ -29,10 +29,11 @@ contentTracing.startRecording('*', contentTracing.DEFAULT_OPTIONS, function() { 모든 child 프로세스가 `getCategories` 요청을 승인하면 `callback`이 한 번 호출되며 인자에 카테고리 그룹의 배열이 전달됩니다. -### `contentTracing.startRecording(categoryFilter, traceOptions, callback)` +### `contentTracing.startRecording(options, callback)` -* `categoryFilter` String -* `traceOptions` String +* `options` Object + * `categoryFilter` String + * `traceOptions` String * `callback` Function 모든 프로세스에서 레코딩을 시작합니다. @@ -85,10 +86,11 @@ Child 프로세스는 일반적으로 추적 데이터와 희귀한 플러시 추적 데이터는 `resultFilePath` 해당 경로가 비어있는 경우에 한 해 해당 경로에 작성되거나 임시 파일에 작성됩니다. 실제 파일 경로는 null이 아닌 이상 `callback`을 통해 전달됩니다. -### `contentTracing.startMonitoring(categoryFilter, traceOptions, callback)` +### `contentTracing.startMonitoring(options, callback)` -* `categoryFilter` String -* `traceOptions` String +* `options` Object + * `categoryFilter` String + * `traceOptions` String * `callback` Function 모든 프로세스에서 모니터링을 시작합니다. diff --git a/docs-translations/ko/api/menu.md b/docs-translations/ko/api/menu.md index 90ea6539829a..89abcf289a78 100644 --- a/docs-translations/ko/api/menu.md +++ b/docs-translations/ko/api/menu.md @@ -295,7 +295,7 @@ OS X에선 지정한 어플리케이션 메뉴에 상관없이 메뉴의 첫번 만약 참조된 아이템의 분리자 그룹이 존재하지 않을 경우 지정된 id로 새로운 분리자 그룹을 만든 후 해당 그룹의 뒤에 삽입됩니다. 위치를 지정한 아이템의 뒤에 위치가 지정되지 않은 아이템이 있을 경우 각 아이템의 위치가 지정되기 전까지 모든 아이템이 위치가 지정된 아이템의 뒤에 삽입됩니다. -이에 따라 위치를 이동하고 싶은 특정 그룹의 아이템들이 있을 경우 해당 그룹의 맨 첫번째 메뉴 아이템의 위치만을 지정하면 됩니다. +따라서 위치를 이동하고 싶은 특정 그룹의 아이템들이 있을 경우 해당 그룹의 맨 첫번째 메뉴 아이템의 위치만을 지정하면 됩니다. ### 예제 diff --git a/docs-translations/ko/api/web-frame.md b/docs-translations/ko/api/web-frame.md index 9829520901d2..d09114e559c8 100644 --- a/docs-translations/ko/api/web-frame.md +++ b/docs-translations/ko/api/web-frame.md @@ -1,4 +1,4 @@ -# web-frame +# webFrame `web-frame` 모듈은 현재 웹 페이지의 랜더링 상태를 설정 할 수 있도록 관련 유틸리티를 제공하는 모듈입니다. @@ -6,38 +6,43 @@ ```javascript var webFrame = require('web-frame'); + webFrame.setZoomFactor(2); ``` -## webFrame.setZoomFactor(factor) +## Methods + +`web-frame` 모듈은 다음과 같은 메서드를 가지고 있습니다: + +### `webFrame.setZoomFactor(factor)` * `factor` Number - Zoom 값 -지정한 값으로 페이지를 줌 합니다. 줌 값은 퍼센트 / 100입니다. (예시: 300% = 3.0) +지정한 값으로 페이지를 줌 합니다. 줌 값은 퍼센트를 100으로 나눈 값입니다. (예시: 300% = 3.0) -## webFrame.getZoomFactor() +### `webFrame.getZoomFactor()` 현재 줌 값을 반환합니다. -## webFrame.setZoomLevel(level) +### `webFrame.setZoomLevel(level)` * `level` Number - Zoom level 지정한 레벨로 줌 레벨을 변경합니다. 0은 "기본 크기" 입니다. 그리고 각각 레벨 값을 올리거나 내릴 때마다 20%씩 커지거나 작아지고 기본 크기의 50%부터 300%까지 조절 제한이 있습니다. -## webFrame.getZoomLevel() +### `webFrame.getZoomLevel()` 현재 줌 레벨을 반환합니다. -## webFrame.setZoomLevelLimits(minimumLevel, maximumLevel) +### `webFrame.setZoomLevelLimits(minimumLevel, maximumLevel)` * `minimumLevel` Number * `maximumLevel` Number 줌 레벨의 최대, 최소치를 지정합니다. -## webFrame.setSpellCheckProvider(language, autoCorrectWord, provider) +### `webFrame.setSpellCheckProvider(language, autoCorrectWord, provider)` * `language` String * `autoCorrectWord` Boolean @@ -57,7 +62,7 @@ require('web-frame').setSpellCheckProvider("en-US", true, { }); ``` -## webFrame.registerUrlSchemeAsSecure(scheme) +### `webFrame.registerUrlSchemeAsSecure(scheme)` * `scheme` String @@ -65,10 +70,10 @@ require('web-frame').setSpellCheckProvider("en-US", true, { 보안 스킴은 혼합된 컨텐츠 경고를 발생시키지 않습니다. 예를 들어 `https` 와 `data`는 네트워크 공격자로부터 손상될 가능성이 없기 때문에 보안 스킴이라고 할 수 있습니다. -## webFrame.registerUrlSchemeAsBypassingCsp(scheme) +### `webFrame.registerUrlSchemeAsBypassingCsp(scheme)` * `scheme` String -페이지 컨텐츠의 보안 정책에 상관없이 이 `scheme`로부터 리소스가 로드됩니다. +현재 페이지 컨텐츠의 보안 정책에 상관없이 이 `scheme`로부터 리소스가 로드됩니다. [spellchecker]: https://github.com/atom/node-spellchecker diff --git a/docs-translations/ko/api/web-view-tag.md b/docs-translations/ko/api/web-view-tag.md index d2efdf17ea1f..0ed8558fa2fd 100644 --- a/docs-translations/ko/api/web-view-tag.md +++ b/docs-translations/ko/api/web-view-tag.md @@ -3,9 +3,9 @@ `guest` 컨텐츠(웹 페이지)를 Electron 앱 페이지에 삽입하기 위해 `webview` 태그를 사용할 수 있습니다. 게스트 컨텐츠는 `webview` 컨테이너에 담겨 대상 페이지에 삽입되고 해당 페이지에선 게스트 컨텐츠의 배치 및 렌더링 과정을 조작할 수 있습니다. -`iframe`과 `webview`의 차이는 어플리케이션과 프로세스가 분리되어 돌아간다는 점입니다. -그것은 모든 권한이 웹 페이지와 같지 않고 모든 앱과 임베디드(게스트) 컨텐츠간의 상호작용이 비동기로 작동한다는 것을 의미합니다. -이에 따라 임베디드 컨텐츠로부터 어플리케이션을 안전하게 유지할 수 있습니다. +`iframe`과는 달리 `webview`는 어플리케이션과 분리된 프로세스에서 작동합니다. +이는 웹 페이지와 같은 권한을 가지지 않고 앱과 임베디드(게스트) 컨텐츠간의 모든 상호작용이 비동기로 작동한다는 것을 의미합니다. +따라서 임베디드 컨텐츠로부터 어플리케이션을 안전하게 유지할 수 있습니다. ## 예제 @@ -40,7 +40,9 @@ ## 태그 속성 -### src +`webview` 태그는 다음과 같은 속성을 가지고 있습니다: + +### `src` ```html @@ -52,17 +54,17 @@ `src` 속성은 `data:text/plain,Hello, world!` 같은 data URL도 사용할 수 있습니다. -### autosize +### `autosize` ```html ``` "on" 으로 지정하면 `webview` 컨테이너는 `minwidth`, `minheight`, `maxwidth`, `maxheight`에 맞춰서 자동으로 크기를 조절합니다. -이 조건은 `autosize`가 활성화되어있지 않는 한 따로 영향을 주지 않습니다. +이 속성들은 `autosize`가 활성화되어있지 않는 한 프레임에 영향을 주지 않습니다. `autosize`가 활성화 되어있으면 `webview` 컨테이너의 크기는 각각의 지정한 최대, 최소값에 따라 조절됩니다. -### nodeintegration +### `nodeintegration` ```html @@ -71,7 +73,7 @@ "on"으로 지정하면 `webview` 페이지 내에서 `require`와 `process 객체`같은 node.js API를 사용할 수 있습니다. 이를 지정하면 내부에서 로우레벨 리소스에 접근할 수 있습니다. -### plugins +### `plugins` ```html @@ -79,46 +81,48 @@ "on"으로 지정하면 `webview` 내부에서 브라우저 플러그인을 사용할 수 있습니다. -### preload +### `preload` ```html ``` -게스트 페이지가 로드되기 전에 실행할 스크립트를 지정합니다. +페이지가 로드되기 전에 실행할 스크립트를 지정합니다. 스크립트 URL은 `file:` 또는 `asar:` 프로토콜 중 하나를 반드시 사용해야 합니다. -왜냐하면 `require`를 사용해 게스트 페이지 내에서 스크립트를 로드하기 때문입니다. +왜냐하면 페이지 내에서 `require`를 사용하여 스크립트를 로드하기 때문입니다. -게스트 페이지가 nodeintegration을 활성화 하지 않았어도 지정된 스크립트는 정상적으로 돌아갑니다. +페이지가 nodeintegration을 활성화 하지 않아도 지정한 스크립트는 정상적으로 작동합니다. 하지만 스크립트 내에서 사용할 수 있는 global 객체는 스크립트 작동이 끝나면 삭제됩니다. -### httpreferrer +### `httpreferrer` ```html ``` -게스트 페이지의 referrer URL을 설정합니다. +페이지의 referrer URL을 설정합니다. -### useragent +### `useragent` ```html ``` -게스트 페이지의 `User-Agent`를 설정합니다. 페이지가 로드된 후엔 `setUserAgent` 메소드를 사용해서 변경할 수 있습니다. +페이지의 `User-Agent`를 설정합니다. 페이지가 로드된 후엔 `setUserAgent` 메소드를 사용해서 변경할 수 있습니다. -### disablewebsecurity +### `disablewebsecurity` ```html ``` -"on"으로 지정하면 게스트 페이지의 웹 보안을 해제합니다. +"on"으로 지정하면 페이지의 웹 보안을 해제합니다. -## API +## Methods -webview 메서드는 페이지 로드가 끝난 뒤에만 사용할 수 있습니다. +`webview` 태그는 다음과 같은 메서드를 가지고 있습니다: + +**참고:** Webview 메서드는 페이지 로드가 끝난 뒤에만 사용할 수 있습니다. **예제** ```javascript @@ -127,229 +131,240 @@ webview.addEventListener("dom-ready", function() { }); ``` -### ``.getUrl() +### `.getUrl()` -게스트 페이지의 URL을 반환합니다. +페이지의 URL을 반환합니다. -### ``.getTitle() +### `.getTitle()` -게스트 페이지의 제목을 반환합니다. +페이지의 제목을 반환합니다. -### ``.isLoading() +### `.isLoading()` -페이지가 아직 리소스를 로딩하고 있는지 확인합니다. +페이지가 아직 리소스를 로딩하고 있는지 확인합니다. 불린 값을 반환합니다. -### ``.isWaitingForResponse() +### `.isWaitingForResponse()` -게스트 페이지가 메인 리소스의 첫 응답을 기다리고 있는지 확인합니다. +페이지가 메인 리소스의 첫 응답을 기다리고 있는지 확인합니다. 불린 값을 반환합니다. -### ``.stop() +### `.stop()` 모든 탐색을 취소합니다. -### ``.reload() +### `.reload()` 페이지를 새로고침합니다. -### ``.reloadIgnoringCache() +### `.reloadIgnoringCache()` 캐시를 무시하고 페이지를 새로고침합니다. -### ``.canGoBack() +### `.canGoBack()` -페이지 히스토리를 한 칸 뒤로 가기를 할 수 있는지 확인합니다. +페이지 히스토리를 한 칸 뒤로 가기를 할 수 있는지 확인합니다. 불린 값을 반환합니다. -### ``.canGoForward() +### `.canGoForward()` -페이지 히스토리를 한 칸 앞으로 가기를 할 수 있는지 확인합니다. +페이지 히스토리를 한 칸 앞으로 가기를 할 수 있는지 확인합니다. 불린 값을 반환합니다. -### ``.canGoToOffset(offset) +### `.canGoToOffset(offset)` * `offset` Integer -페이지 히스토리를 `offset` 만큼 이동할 수 있는지 확인합니다. +페이지 히스토리를 `offset` 만큼 이동할 수 있는지 확인합니다. 불린값을 반환합니다. -### ``.clearHistory() +### `.clearHistory()` 탐색 히스토리를 비웁니다. -### ``.goBack() +### `.goBack()` 페이지 뒤로 가기를 실행합니다. -### ``.goForward() +### `.goForward()` 페이지 앞으로 가기를 실행합니다. -### ``.goToIndex(index) +### `.goToIndex(index)` * `index` Integer 페이지를 지정한 `index`로 이동합니다. -### ``.goToOffset(offset) +### `.goToOffset(offset)` * `offset` Integer -현재 페이지로 부터 `offset` 만큼 이동합니다. +페이지로부터 `offset` 만큼 이동합니다. -### ``.isCrashed() +### `.isCrashed()` 랜더러 프로세스가 크래시 됬는지 확인합니다. -### ``.setUserAgent(userAgent) +### `.setUserAgent(userAgent)` * `userAgent` String `User-Agent`를 지정합니다. -### ``.getUserAgent() +### `.getUserAgent()` -현재 페이지의 `User-Agent` 문자열을 가져옵니다. +페이지의 `User-Agent 문자열`을 가져옵니다. -### ``.insertCSS(css) +### `.insertCSS(css)` * `css` String -게스트 페이지에 CSS를 삽입합니다. +페이지에 CSS를 삽입합니다. -### ``.executeJavaScript(code[, userGesture]) +### `.executeJavaScript(code[, userGesture])` * `code` String * `userGesture` Boolean -게스트 페이지에서 자바스크립트 `code`를 실행합니다. +페이지에서 자바스크립트 `code`를 실행합니다. -`userGesture`가 `true`로 설정되어 있으면 `requestFullScreen` HTML API 같이 -유저의 승인이 필요한 API를 유저의 승인을 무시하고 개발자가 API를 직접 사용할 수 있습니다. +만약 `userGesture`가 `true`로 설정되어 있으면 페이지에 유저 제스쳐 컨텍스트를 만듭니다. +이 옵션을 활성화 시키면 `requestFullScreen`와 같은 HTML API에서 유저의 승인을 무시하고 개발자가 API를 바로 사용할 수 있도록 허용합니다. 역주: 기본적으로 브라우저에선 전체화면, 웹캠, 파일 열기등의 API를 사용하려면 유저의 승인(이벤트)이 필요합니다. -### ``.openDevTools() +### `.openDevTools()` -게스트 페이지에 대한 개발자 툴을 엽니다. +페이지에 대한 개발자 툴을 엽니다. -### ``.closeDevTools() +### `.closeDevTools()` -게스트 페이지에 대한 개발자 툴을 닫습니다. +페이지에 대한 개발자 툴을 닫습니다. -### ``.isDevToolsOpened() +### `.isDevToolsOpened()` -게스트 페이지에 대한 개발자 툴이 열려있는지 확인합니다. +페이지에 대한 개발자 툴이 열려있는지 확인합니다. 불린 값을 반환합니다. -### ``.inspectElement(x, y) +### `.inspectElement(x, y)` * `x` Integer * `y` Integer (`x`, `y`) 위치에 있는 엘리먼트를 inspect합니다. -### ``.inspectServiceWorker() +### `.inspectServiceWorker()` Service worker에 대한 개발자 툴을 엽니다. -### ``.undo() +### `.undo()` 페이지에서 실행 취소 커맨드를 실행합니다. -### ``.redo() +### `.redo()` 페이지에서 다시 실행 커맨드를 실행합니다. -### ``.cut() +### `.cut()` 페이지에서 잘라내기 커맨드를 실행합니다. -### ``.copy() +### `.copy()` 페이지에서 복사 커맨드를 실행합니다. -### ``.paste() +### `.paste()` 페이지에서 붙여넣기 커맨드를 실행합니다. -### ``.pasteAndMatchStyle() +### `.pasteAndMatchStyle()` 페이지에서 `pasteAndMatchStyle` 편집 커맨드를 실행합니다. -### ``.delete() +### `.delete()` 페이지에서 삭제 커맨드를 실행합니다. -### ``.selectAll() +### `.selectAll()` 페이지에서 전체 선택 커맨드를 실행합니다. -### ``.unselect() +### `.unselect()` 페이지에서 `unselect` 커맨드를 실행합니다. -### ``.replace(text) +### `.replace(text)` * `text` String 페이지에서 `replace` 커맨드를 실행합니다. -### ``.replaceMisspelling(text) +### `.replaceMisspelling(text)` * `text` String 페이지에서 `replaceMisspelling` 커맨드를 실행합니다. -### ``.print([options]) +### `.print([options])` Webview 페이지를 인쇄합니다. `webContents.print([options])` 메서드와 같습니다. -### ``.printToPDF(options, callback) +### `.printToPDF(options, callback)` Webview 페이지를 PDF 형식으로 인쇄합니다. `webContents.printToPDF(options, callback)` 메서드와 같습니다. -### ``.send(channel[, args...]) +### `.send(channel[, args...])` * `channel` String +* `args` (optional) -`channel`을 통해 게스트 페이지에 `args...` 비동기 메시지를 보냅니다. -게스트 페이지에선 `ipc` 모듈의 `channel` 이벤트를 사용하면 이 메시지를 받을 수 있습니다. +`channel`을 통해 페이지에 `args` 비동기 메시지를 보냅니다. +페이지에선 `ipc` 모듈의 `channel` 이벤트를 사용하면 이 메시지를 받을 수 있습니다. 예제는 [WebContents.send](browser-window.md#webcontentssendchannel-args)를 참고하세요. ## DOM 이벤트 -### load-commit +`webview` 태그는 다음과 같은 DOM 이벤트를 가지고 있습니다: + +### Event: 'load-commit' + +Returns: * `url` String * `isMainFrame` Boolean -Fired when a load has committed. This includes navigation within the current -document as well as subframe document-level loads, but does not include -asynchronous resource loads. +로드가 시작됬을 때 발생하는 이벤트입니다. +이 이벤트는 현재 문서내의 탐색뿐만 아니라 서브 프레임 문서 레벨의 로드도 포함됩니다. +하지만 비동기 리소스 로드는 포함되지 않습니다. -### did-finish-load +### Event: 'did-finish-load' -탐색이 끝나면 발생하는 이벤트입니다. 브라우저 탭의 스피너가 멈추고 `onload` 이벤트가 발생될 때를 생각하면 됩니다. +탐색이 끝나면 발생하는 이벤트입니다. 브라우저 탭의 스피너가 멈추고 `onload` 이벤트가 발생할 때를 생각하면 됩니다. -### did-fail-load +### Event: 'did-fail-load' + +Returns: * `errorCode` Integer * `errorDescription` String `did-finish-load`와 비슷합니다. 하지만 이 이벤트는 `window.stop()`과 같은 무언가로 인해 로드에 실패했을 때 발생하는 이벤트입니다. -### did-frame-finish-load +### Event: 'did-frame-finish-load' + +Returns: * `isMainFrame` Boolean 프레임의 탐색이 끝나면 발생하는 이벤트입니다. -### did-start-loading +### Event: 'did-start-loading' 브라우저 탭의 스피너가 돌기 시작할 때 처럼 페이지의 로드가 시작될 때 발생하는 이벤트입니다. -### did-stop-loading +### Event: 'did-stop-loading' 브라우저 탭의 스피너가 멈출 때 처럼 페이지의 로드가 끝나면 발생하는 이벤트입니다. -### did-get-response-details +### Event: 'did-get-response-details' + +Returns: * `status` Boolean * `newUrl` String @@ -362,7 +377,9 @@ asynchronous resource loads. 요청한 리소스에 관해 자세한 내용을 알 수 있을 때 발생하는 이벤트입니다. `status`는 리소스를 다운로드할 소켓 커낵션을 나타냅니다. -### did-get-redirect-request +### Event: 'did-get-redirect-request' + +Returns: * `oldUrl` String * `newUrl` String @@ -370,32 +387,38 @@ asynchronous resource loads. 리소스를 요청하고 받는 도중에 리다이렉트가 생기면 발생하는 이벤트입니다. -### dom-ready +### Event: 'dom-ready' -현재 프레임 문서의 로드가 끝나면 발생하는 이벤트입니다. +프레임 문서의 로드가 끝나면 발생하는 이벤트입니다. -### page-title-set +### Event: 'page-title-set' + +Returns: * `title` String * `explicitSet` Boolean 탐색하는 동안에 페이지의 제목이 설정되면 발생하는 이벤트입니다. `explicitSet`는 파일 URL에서 종합(synthesised)된 제목인 경우 false로 표시됩니다. -### page-favicon-updated +### Event: 'page-favicon-updated' -* `favicons` Array - Array of Urls +Returns: + +* `favicons` Array - URL 배열 페이지가 favicon URL을 받았을 때 발생하는 이벤트입니다. -### enter-html-full-screen +### Event: 'enter-html-full-screen' 페이지가 HTML API에 의해 전체 화면 모드에 돌입했을 때 발생하는 이벤트입니다. -### leave-html-full-screen +### Event: 'leave-html-full-screen' 페이지의 전체 화면 모드가 해제됬을 때 발생하는 이벤트입니다. -### console-message +### Event: 'console-message' + +Returns: * `level` Integer * `message` String @@ -412,14 +435,16 @@ webview.addEventListener('console-message', function(e) { }); ``` -### new-window +### Event: 'new-window' + +Returns: * `url` String * `frameName` String * `disposition` String - Can be `default`, `foreground-tab`, `background-tab`, `new-window` and `other` -게스트 페이지가 새로운 브라우저 창을 생성할 때 발생하는 이벤트입니다. +페이지가 새로운 브라우저 창을 생성할 때 발생하는 이벤트입니다. 다음 예제 코드는 새 URL을 시스템의 기본 브라우저로 여는 코드입니다. @@ -429,11 +454,11 @@ webview.addEventListener('new-window', function(e) { }); ``` -### close +### Event: 'close' -게스트 페이지가 자체적으로 닫힐 때 발생하는 이벤트입니다. +페이지가 자체적으로 닫힐 때 발생하는 이벤트입니다. -다음 예제 코드는 게스트 페이지가 자체적으로 닫힐 때 `webview`를 `about:blank` 페이지로 이동시키는 예제입니다. +다음 예제 코드는 페이지가 자체적으로 닫힐 때 `webview`를 `about:blank` 페이지로 이동시키는 예제입니다. ```javascript webview.addEventListener('close', function() { @@ -441,7 +466,9 @@ webview.addEventListener('close', function() { }); ``` -### ipc-message +### Event: 'ipc-message' + +Returns: * `channel` String * `args` Array @@ -467,21 +494,23 @@ ipc.on('ping', function() { }); ``` -### crashed +### Event: 'crashed' 랜더러 프로세스가 크래시 되었을 때 발생하는 이벤트입니다. -### gpu-crashed +### Event: 'gpu-crashed' GPU 프로세스가 크래시 되었을 때 발생하는 이벤트입니다. -### plugin-crashed +### Event: 'plugin-crashed' + +Returns: * `name` String * `version` String 플러그인 프로세스가 크래시 되었을 때 발생하는 이벤트입니다. -### destroyed +### Event: 'destroyed' WebContents가 파괴될 때 발생하는 이벤트입니다. diff --git a/docs-translations/ko/api/window-open.md b/docs-translations/ko/api/window-open.md index 6d7c0b9fabbe..4187672331f4 100644 --- a/docs-translations/ko/api/window-open.md +++ b/docs-translations/ko/api/window-open.md @@ -4,17 +4,17 @@ 이 창은 지정한 `url`을 로드하여 만들어진 `BrowserWindow`의 새 인스턴스이며 본래 창 객체 대신 페이지의 컨트롤이 제한된 프록시 객체를 반환합니다. 프록시 객체는 브라우저의 웹 페이지 창과 호환될 수 있도록 일부 제한된 표준 기능만 가지고 있습니다. -창의 모든 컨트롤을 가지려면 `BrowserWindow`를 직접 생성하여 작업해야 합니다. +창의 모든 컨트롤 권한을 가지려면 `BrowserWindow`를 직접 생성해서 사용해야 합니다. -## window.open(url, [frameName[, features]]) +### `window.open(url[, frameName][, features])` * `url` String -* `frameName` String -* `features` String +* `frameName` String (optional) +* `features` String (optional) `BrowserWindowProxy` 클래스의 객체를 반환하는 새로운 윈도우를 생성합니다. -## window.opener.postMessage(message, targetOrigin) +### `window.opener.postMessage(message, targetOrigin)` * `message` String * `targetOrigin` String @@ -23,31 +23,31 @@ ## Class: BrowserWindowProxy -### BrowserWindowProxy.blur() +### `BrowserWindowProxy.blur()` 자식 윈도우의 포커스를 해제합니다. -### BrowserWindowProxy.close() +### `BrowserWindowProxy.close()` 자식 윈도우를 강제로 닫습니다. unload 이벤트가 발생하지 않습니다. Forcefully closes the child window without calling its unload event. -### BrowserWindowProxy.closed +### `BrowserWindowProxy.closed` 자식 윈도우가 닫히면 true로 설정됩니다. -### BrowserWindowProxy.eval(code) +### `BrowserWindowProxy.eval(code)` * `code` String 자식 윈도우에서 특정 스크립트를 실행합니다. -### BrowserWindowProxy.focus() +### `BrowserWindowProxy.focus()` 자식 윈도우에 포커스를 맞춥니다. (창을 맨 앞으로 가져옵니다) -### BrowserWindowProxy.postMessage(message, targetOrigin) +### `BrowserWindowProxy.postMessage(message, targetOrigin)` * `message` String * `targetOrigin` String diff --git a/docs-translations/ko/development/atom-shell-vs-node-webkit.md b/docs-translations/ko/development/atom-shell-vs-node-webkit.md index aa0d3e19058f..ec35a2dbf1f4 100644 --- a/docs-translations/ko/development/atom-shell-vs-node-webkit.md +++ b/docs-translations/ko/development/atom-shell-vs-node-webkit.md @@ -1,15 +1,16 @@ -# NW.js와 기술적으로 다른점 (이전 node-webkit) +# Electron이 NW.js(node-webkit)와 기술적으로 다른점 __주의: 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) 파일을 지정하면 어플리케이션의 메인 윈도우로 열리게 됩니다. +`package.json`내의 main 필드에 메인 웹 페이지(index.html) URL을 지정하면 어플리케이션의 메인 윈도우로 열리게 됩니다. Electron에선 JavaScript를 엔트리 포인트로 사용합니다. URL을 직접 제공하는 대신 API를 사용하여 직접 브라우저 창과 HTML 파일을 로드할 수 있습니다. 또한 윈도우의 종료시기를 결정하는 이벤트를 리스닝해야합니다. diff --git a/docs-translations/ko/development/build-instructions-linux.md b/docs-translations/ko/development/build-instructions-linux.md index e02c1341f993..cb254a80596d 100644 --- a/docs-translations/ko/development/build-instructions-linux.md +++ b/docs-translations/ko/development/build-instructions-linux.md @@ -1,11 +1,13 @@ # 빌드 설명서 (Linux) +이 가이드는 Linux 운영체제에서 Electron을 빌드하는 방법을 설명합니다. + ## 빌드전 요구사양 * Python 2.7.x. 몇몇 CentOS와 같은 배포판들은 아직도 Python 2.6.x 버전을 사용합니다. 그래서 `python -V`를 통해 버전을 확인해 줄 필요가 있습니다. * Node.js v0.12.x. Node를 설치하는 방법은 여러가지가 있습니다. 그중 하나는 [Node.js](http://nodejs.org) 사이트에서 소스코드를 받아 빌드하는 방법입니다. -이렇게 하면 Node를 일반 유저로 홈 디렉터리에 설치할 수 있습니다. 또는 [NodeSource](https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories)에서 소스 파일을 받아올 수 있습니다. -자세한 내용은 [Node.js 설치 방법](https://github.com/joyent/node/wiki/Installation) 을 참고하세요. + 이렇게 하면 Node를 일반 유저로 홈 디렉터리에 설치할 수 있습니다. 또는 [NodeSource](https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories)에서 소스 파일을 받아올 수 있습니다. + 자세한 내용은 [Node.js 설치 방법](https://github.com/joyent/node/wiki/Installation) 을 참고하세요. * Clang 3.4 또는 최신 버전 * GTK+ 와 libnotify의 개발용 헤더 @@ -54,7 +56,7 @@ $ ./script/bootstrap.py -v ### 크로스 컴파일 -`arm` 아키텍쳐로 빌드 하려면 먼저 종속성 라이브러리를 설치해야 합니다: +`arm` 아키텍쳐로 빌드 하려면 다음 종속성 라이브러리를 설치해야 합니다: ```bash $ sudo apt-get install libc6-dev-armhf-cross linux-libc-dev-armhf-cross \ @@ -84,7 +86,7 @@ $ ./script/create-dist.py ``` 이 스크립트는 매우 작은 배포판을 `dist` 디렉터리에 생성합니다. -create-dist.py 스크립트를 실행한 이후 1.3GB를 초과하는 공간을 차지하는 out/R 폴더의 실행파일 바이너리는 삭제해도 됩니다. +create-dist.py 스크립트를 실행한 이후부턴 1.3GB를 초과하는 공간을 차지하는 `out/R` 폴더의 바이너리는 삭제해도 됩니다. 또는 `Debug` 타겟만 빌드 할 수 있습니다: @@ -109,7 +111,7 @@ $ ./script/clean.py ## libtinfo.so.5 동적 링크 라이브러리를 로드하는 도중 에러가 발생할 경우 미리 빌드된 `clang`은 `libtinfo.so.5`로 링크를 시도합니다. -플랫폼에 따라 적당한 `libncurses` symlink를 추가하세요. +따라서 플랫폼에 따라 적당한 `libncurses` symlink를 추가하세요: ```bash $ sudo ln -s /usr/lib/libncurses.so.5 /usr/lib/libtinfo.so.5 diff --git a/docs-translations/ko/development/build-instructions-mac.md b/docs-translations/ko/development/build-instructions-osx.md similarity index 76% rename from docs-translations/ko/development/build-instructions-mac.md rename to docs-translations/ko/development/build-instructions-osx.md index eeed5a4df4ec..4951b975ae33 100644 --- a/docs-translations/ko/development/build-instructions-mac.md +++ b/docs-translations/ko/development/build-instructions-osx.md @@ -1,12 +1,14 @@ -# 빌드 설명서 (Mac) +# 빌드 설명서 (OS X) + +이 가이드는 OS X 운영체제에서 Electron을 빌드하는 방법을 설명합니다. ## 빌드전 요구 사항 * 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) -만약 Homebrew를 이용해 파이선을 설치했다면 다음 파이선 모듈도 같이 설치해야 합니다: +만약 Homebrew를 이용해 파이선을 설치했다면 다음 Python 모듈도 같이 설치해야 합니다: * pyobjc @@ -44,7 +46,7 @@ $ ./script/build.py -c D ## 32비트 지원 -Electron은 현재 OS X 64비트 빌드만 지원하고 있습니다. 그리고 앞으로도 OS X 32비트는 지원할 계획이 없습니다. +Electron은 현재 OS X 64비트만 지원하고 있습니다. 그리고 앞으로도 OS X 32비트는 지원할 계획이 없습니다. ## 테스트 diff --git a/docs-translations/ko/development/build-instructions-windows.md b/docs-translations/ko/development/build-instructions-windows.md index 22734b1ec236..fa165ca153ac 100644 --- a/docs-translations/ko/development/build-instructions-windows.md +++ b/docs-translations/ko/development/build-instructions-windows.md @@ -1,25 +1,29 @@ # 빌드 설명서 (Windows) +이 가이드는 Windows 운영체제에서 Electron을 빌드하는 방법을 설명합니다. + ## 빌드전 요구 사항 * Windows 7 / Server 2008 R2 또는 최신 버전 * Visual Studio 2013 - [VS 2013 커뮤니티 에디션 무료 다운로드](http://www.visualstudio.com/products/visual-studio-community-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) -현재 Windows를 설치하지 않았다면 [modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads)에서 +현재 사용하고 있는 PC에 Windows를 설치하지 않았다면 [modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads)에서 사용 기한이 정해져있는 무료 가상머신 버전의 Windows를 받아 Electron을 빌드하는 방법도 있습니다. -Electron은 전적으로 command-line 스크립트를 사용하여 빌드합니다. 그렇기에 Electron을 개발하는데 아무런 에디터나 사용할 수 있습니다. -하지만 이 말은 Visual Studio를 개발을 위해 사용할 수 없다는 말이 됩니다. 나중에 Visual Studio를 이용한 빌드 방법도 제공할 예정입니다. +Electron은 모든 빌드를 command-line 스크립트를 통해 빌드합니다. 따라서 빌드에 Visual Studio를 사용할 수 없습니다. +하지만 여전히 Electron을 개발할 땐 아무 에디터나 사용할 수 있습니다. 빠른 시일내에 Visual Studio를 이용한 빌드도 지원할 계획입니다. -**참고:** Visual Studio가 빌드에 사용되지 않더라도 제공된 빌드 툴체인이 **필수적으로** 사용되므로 여전히 필요합니다. +**참고:** Visual Studio가 직접 빌드에 사용되지 않더라도 IDE와 같이 제공된 빌드 툴체인이 빌드에 **필수적으로** 사용되므로 여전히 필요합니다. + +**참고:** Visual Studio 2015는 사용할 수 없습니다. MSVS **2013**을 사용하고 있는지 확인해주세요. ## 코드 가져오기 ```powershell -git clone https://github.com/atom/electron.git +$ git clone https://github.com/atom/electron.git ``` ## 부트 스트랩 @@ -28,8 +32,8 @@ git clone https://github.com/atom/electron.git 참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Visual Studio 프로젝트는 생성되지 않습니다. ```powershell -cd electron -python script\bootstrap.py -v +$ cd electron +$ python script\bootstrap.py -v ``` ## 빌드 하기 @@ -37,13 +41,13 @@ python script\bootstrap.py -v `Release` 와 `Debug` 두 타겟 모두 빌드 합니다: ```powershell -python script\build.py +$ python script\build.py ``` 또는 `Debug` 타겟만 빌드 할 수 있습니다: ```powershell -python script\build.py -c D +$ python script\build.py -c D ``` 빌드가 모두 끝나면 `out/D` (디버그 타겟) 또는 `out/R` (릴리즈 타겟) 디렉터리에서 `electron.exe` 실행 파일을 찾을 수 있습니다. @@ -53,7 +57,7 @@ python script\build.py -c D 64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때 `--target_arch=x64` 인자를 같이 넘겨주면 됩니다: ```powershell -python script\bootstrap.py -v --target_arch=x64 +$ python script\bootstrap.py -v --target_arch=x64 ``` 다른 빌드 단계도 정확하게 같습니다. @@ -63,13 +67,13 @@ python script\bootstrap.py -v --target_arch=x64 프로젝트 코딩 스타일을 확인하려면: ```powershell -python script\cpplint.py +$ python script\cpplint.py ``` 테스트를 실행하려면: ```powershell -python script\test.py +$ python script\test.py ``` 테스트 실행시 `runas`와 같은 네이티브 모듈을 포함하는데 이 모듈은 디버그 빌드에서 같이 사용할 수 없습니다. @@ -78,7 +82,7 @@ python script\test.py 릴리즈 빌드로 테스트를 실행하려면 다음 커맨드를 사용하면 됩니다: ```powershell -python script\test.py -R +$ python script\test.py -R ``` ## 문제 해결 @@ -110,23 +114,24 @@ Traceback (most recent call last): 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 +$ /cygdrive/c/Python27/python.exe script/bootstrap.py ``` ### LNK1181: cannot open input file 'kernel32.lib' -32bit node.js를 다시 설치하세요. +32비트 Node.js를 다시 설치하세요. ### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm' 간단하게 해당 디렉터리를 생성하면 [문제가 해결될 겁니다](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 diff --git a/docs-translations/ko/development/build-system-overview.md b/docs-translations/ko/development/build-system-overview.md index 7198fa831b92..34f93a8881bd 100644 --- a/docs-translations/ko/development/build-system-overview.md +++ b/docs-translations/ko/development/build-system-overview.md @@ -3,7 +3,7 @@ Electron은 프로젝트 생성을 위해 `gyp`를 사용하며 `ninja`를 이용하여 빌드합니다. 프로젝트 설정은 `.gyp` 와 `.gypi` 파일에서 볼 수 있습니다. -## gyp 파일들 +## gyp 파일 Electron을 빌드 할 때 `gyp` 파일들은 다음과 같은 규칙을 따릅니다: @@ -15,8 +15,8 @@ Electron을 빌드 할 때 `gyp` 파일들은 다음과 같은 규칙을 따릅 ## 구성요소 빌드 Chromium은 꽤나 큰 프로젝트입니다. 이 때문에 최종 링킹 작업은 상당한 시간이 소요될 수 있습니다. -이러한 문제로 인해 개발 시 빌드 작업을 까다롭게 만듭니다. 이 문제를 해결하기 위해 Chromium은 "component build"를 도입했습니다. -이는 각각의 컴포넌트를 각각 따로 분리하여 공유 라이브러리로 빌드 합니다. 이렇게 되면 링킹작업은 매우 빨라지지만 파일 크기와 성능이 느려집니다. +이 문제는 보통 개발을 어렵게 만듭니다. 우리는 이 문제를 해결하기 위해 Chromium의 "component build" 방식을 도입했습니다. +이는 각각의 컴포넌트를 각각 따로 분리하여 공유 라이브러리로 빌드 합니다. 하지만 이 방식을 사용하면 링킹 작업은 매우 빨라지지만 파일 크기와 성능이 느려집니다. Electron도 상당히 비슷한 접근을 했습니다: `Debug`빌드 시 바이너리는 공유 라이브러리 버전의 Chromium 컴포넌트를 사용해서 링크 속도를 높이고 @@ -28,7 +28,7 @@ Electron도 상당히 비슷한 접근을 했습니다: Prebuilt된 모든 Chromium 바이너리들은 부트스트랩 스크립트가 실행될 때 다운로드됩니다. 기본적으로 공유 라이브러리와 정적 라이브러리 모두 다운로드되며 최종 전체 파일 크기는 플랫폼에 따라 800MB에서 2GB까지 차지합니다. -기본적으로 libchromiumcontent는 Amazon Web Service를 통해 다운로드 됩니다. +기본적으로 (`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/`를 통해 다운로드 할 수 있습니다. @@ -43,9 +43,9 @@ $ ./script/build.py -c D ## 프로젝트 생성 (two-phrase) Electron은 `Release`와 `Debug` 빌드가 서로 다른 라이브러리 링크 방식을 사용합니다. -그러나 `gyp`는 따로 빌드 설정을 분리하여 라이브러리 링크 방식을 정의하는 것을 지원하지 않습니다. +하지만 `gyp`는 따로 빌드 설정을 분리하여 라이브러리 링크 방식을 정의하는 것을 지원하지 않습니다. -이러한 문제를 해결하기 위해 Electron은 링크 설정을 제어하는 `gyp` 변수 `libchromiumcontent_component`를 사용하고 `gyp`를 실행할 때 단 하나의 타겟만을 생성합니다. +이 문제를 해결하기 위해 Electron은 링크 설정을 제어하는 `gyp` 변수 `libchromiumcontent_component`를 사용하고 `gyp`를 실행할 때 단 하나의 타겟만 생성합니다. ## 타겟 이름 diff --git a/docs-translations/ko/development/coding-style.md b/docs-translations/ko/development/coding-style.md index 1b88be8487c1..0dc16ba0ad68 100644 --- a/docs-translations/ko/development/coding-style.md +++ b/docs-translations/ko/development/coding-style.md @@ -1,21 +1,24 @@ # 코딩 스타일 +이 가이드는 Electron의 코딩 스타일에 관해 설명합니다. + ## C++과 Python -C++과 Python스크립트는 Chromium의 [코딩 스타일](http://www.chromium.org/developers/coding-style)을 따릅니다. +C++과 Python 스크립트는 Chromium의 [코딩 스타일](http://www.chromium.org/developers/coding-style)을 따릅니다. 파이선 스크립트 `script/cpplint.py`를 사용하여 모든 파일이 해당 코딩스타일에 맞게 코딩 되었는지 확인할 수 있습니다. -파이선의 버전은 2.7을 사용합니다. +Python 버전은 2.7을 사용합니다. -C++ 코드는 많은 Chromium의 추상화와 타입을 사용합니다. 그래서 이에 대해 잘 알고 있어야 합니다. +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`를 diff --git a/docs-translations/ko/development/source-code-directory-structure.md b/docs-translations/ko/development/source-code-directory-structure.md index f0c9cde40780..f31d0847db75 100644 --- a/docs-translations/ko/development/source-code-directory-structure.md +++ b/docs-translations/ko/development/source-code-directory-structure.md @@ -1,40 +1,43 @@ # 소스 코드 디렉터리 구조 -## 개요 - -Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 우리는 Chromium의 분리 규칙(separation conventions)을 주로 따르고 있습니다. +Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 그리고 Chromium의 분리 규칙(separation conventions)을 주로 따르고 있습니다. 이미 [Chromium의 멀티 프로세스 아키텍쳐](http://dev.chromium.org/developers/design-documents/multi-process-architecture)에 익숙해져 있다면 소스 코드를 이해하기 쉬울 것입니다. ## 소스 코드 구조 -* **atom** - Electron의 소스코드. - * **app** - 시스템 엔트리 코드. - * **browser** - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것들. 주 랜더러와 웹 페이지 관리관련 코드. - * **lib** - 메인 프로세스 초기화 코드의 자바스크립트 파트. - * **ui** - 크로스 플랫폼에 대응하는 UI 구현. - * **cocoa** - 코코아 특정 소스 코드. - * **gtk** - GTK+ 특정 소스 코드. - * **win** - Windows GUI 특정 소스 코드. - * **default_app** - 어플리케이션이 제공되지 않으면 기본적으로 사용될 페이지. - * **api** - 메인 프로세스 API들의 구현. - * **lib** - API 구현의 자바스크립트 파트. - * **net** - 네트워크 관련 코드. - * **mac** - Mac 특정 Objective-C 소스 코드. - * **resources** - 아이콘들, 플랫폼 종속성 파일들, 기타 등등. - * **renderer** - 렌더러 프로세스에서 작동하는 코드들. - * **lib** - 렌더러 프로세스 초기화 코드의 자바스크립트 파트. - * **api** - 렌더러 프로세스 API들의 구현. - * **lib** - API 구현의 자바스크립트 파트. - * **common** - 메인 프로세스와 렌더러 프로세스에서 공유하는 코드. 유틸리티 함수와 node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드가 포함. - * **lib** - 공통 자바스크립트 초기화 코드. - * **api** - 공통 API들의 구현, Electron의 빌트인 모듈 기초 코드들. - * **lib** - API 구현의 자바스크립트 파트. -* **chromium_src** - 복사된 Chromium 소스 코드. -* **docs** - 참조 문서. -* **spec** - 자동화된 테스트. -* **atom.gyp** - Electron의 빌드 규칙. -* **common.gypi** - 컴파일러 설정 및 `node` 와 `breakpad` 등의 구성요소를 위한 빌드 규칙. +``` +Electron +├──atom - Electron의 소스코드. +| ├── app - 시스템 엔트리 코드. +| ├── browser - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것들. +| | | 랜더러와 웹 페이지 관리 관련 코드. +| | ├── lib - 메인 프로세스 초기화 코드의 자바스크립트 파트. +| | ├── ui - 크로스 플랫폼에 대응하는 UI 구현. +| | | ├── cocoa - 코코아 특정 소스 코드. +| | | ├── gtk - GTK+ 특정 소스 코드. +| | | └── win - Windows GUI 특정 소스 코드. +| | ├── default_app - 어플리케이션이 제공되지 않으면 기본으로 사용되는 페이지. +| | ├── api - 메인 프로세스 API의 구현. +| | | └── lib - API 구현의 자바스크립트 파트. +| | ├── net - 네트워크 관련 코드. +| | ├── mac - Mac 특정 Objective-C 소스 코드. +| | └── resources - 아이콘들, 플랫폼 종속성 파일들, 기타 등등. +| ├── renderer - 랜더러 프로세스에서 작동하는 코드들. +| | ├── lib - 랜더러 프로세스 초기화 코드의 자바스크립트 파트. +| | └── api - 랜더러 프로세스 API들의 구현. +| | └── lib - API 구현의 자바스크립트 파트. +| └── common - 메인 프로세스와 랜더러 프로세스에서 공유하는 코드. +| | 유틸리티 함수와 node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드도 포함. +| ├── lib - 공통 자바스크립트 초기화 코드. +| └── api - 공통 API들의 구현, Electron의 빌트인 모듈 기초 코드들. +| └── lib - API 구현의 자바스크립트 파트. +├── chromium_src - 복사된 Chromium 소스 코드. +├── docs - 참조 문서. +├── spec - 자동화된 테스트. +├── atom.gyp - Electron의 빌드 규칙. +└── common.gypi - 컴파일러 설정 및 `node` 와 `breakpad` 등의 구성요소를 위한 빌드 규칙. +``` ## 그외 디렉터리 구조 @@ -45,4 +48,4 @@ Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 우 * **node_modules** - 빌드에 사용되는 node 서드파티 모듈. * **out** - `ninja`의 임시 출력 디렉터리. * **dist** - 배포용 바이너리를 빌드할 때 사용하는 `script/create-dist.py` 스크립트로부터 만들어지는 임시 디렉터리. -* **external_binaries** - `gyp`를 통한 빌드가 지원하지 않아 따로 다운로드된 서드파티 프레임워크 바이너리들. +* **external_binaries** - `gyp` 빌드를 지원하지 않아 따로 다운로드된 서드파티 프레임워크 바이너리들. diff --git a/docs-translations/ko/tutorial/application-distribution.md b/docs-translations/ko/tutorial/application-distribution.md index fac2ae48a140..69269500733a 100644 --- a/docs-translations/ko/tutorial/application-distribution.md +++ b/docs-translations/ko/tutorial/application-distribution.md @@ -1,7 +1,9 @@ # 어플리케이션 배포 -Electron 어플리케이션을 배포하려면 어플리케이션 폴더 이름을 `app`으로 지정한 후 Electron 실행파일의 리소스 디렉터리에 집어넣기만 하면 됩니다. -리소스 디렉터리는 OS X에선 `Electron.app/Contents/Resources/` Windows와 Linux에선 `resources/` 입니다. +Electron 어플리케이션을 배포하는 방법은 간단합니다. + +먼저 폴더 이름을 `app`로 지정한 후 Electron 리소스 디렉터리에 폴더를 통째로 집어넣기만 하면 됩니다. +리소스 디렉터리는 OS X: `Electron.app/Contents/Resources/` Windows와 Linux: `resources/` 입니다. 예제: @@ -32,7 +34,7 @@ electron/resources/app 어플리케이션의 소스코드가 사용자에게 노출되는 것을 방지할 수 있습니다. `asar` 아카이브를 사용할 땐 단순히 `app` 폴더 대신에 어플리케이션을 패키징한 `app.asar` 파일로 대체하면됩니다. -이렇게 하면 Electron은 아카이브를 `app`폴더 대신 asar 아카이브를 기반으로 어플리케이션을 실행합니다. +Electron은 자동으로 `app`폴더 대신 asar 아카이브를 기반으로 어플리케이션을 실행합니다. OS X의 경우: diff --git a/docs-translations/ko/tutorial/application-packaging.md b/docs-translations/ko/tutorial/application-packaging.md index 0f8169089516..d7a96dbb4b43 100644 --- a/docs-translations/ko/tutorial/application-packaging.md +++ b/docs-translations/ko/tutorial/application-packaging.md @@ -8,7 +8,7 @@ Windows에서 일어나는 긴 경로 이름에 대한 [issues](https://github.c [asar][asar] 아카이브는 tar과 비슷한 포맷으로 모든 리소스를 하나의 파일로 만듭니다. 그리고 Electron은 압축해제 없이 임의로 모든 파일을 읽어들일 수 있습니다. -다음 몇가지 단계를 통해 어플리케이션을 `asar` 아카이브로 압축할 수 있습니다: +간단한 작업을 통해 어플리케이션을 `asar` 아카이브로 압축할 수 있습니다: ### 1. asar 유틸리티 설치 @@ -24,13 +24,13 @@ $ asar pack your-app app.asar ## `asar` 아카이브 사용하기 -Electron은 Node.js로 부터 제공된 Node API와 Chromium으로부터 제공된 Web API 두가지의 API를 가지고 있습니다. -두 API 모두 `asar`에서 읽어들일 수 있도록 지원합니다. +Electron은 Node.js로 부터 제공된 Node API와 Chromium으로부터 제공된 Web API 두 가지 API를 가지고 있습니다. +따라서 `asar` 아카이브는 두 API 모두 사용할 수 있도록 지원합니다. ### Node API Electron에선 `fs.readFile`과 `require` 같은 Node API들을 지원하기 위해 `asar` 아카이브가 가상의 디렉터리 구조를 가지도록 -패치했습니다. 그래서 아카이브 내부에서 리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다. +패치했습니다. 그래서 아카이브 내부 리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다. 예를 들어 `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면: diff --git a/docs-translations/ko/tutorial/debugging-main-process.md b/docs-translations/ko/tutorial/debugging-main-process.md index dcaf6bc9bf36..c11f3db04f3a 100644 --- a/docs-translations/ko/tutorial/debugging-main-process.md +++ b/docs-translations/ko/tutorial/debugging-main-process.md @@ -1,13 +1,15 @@ # 메인 프로세스 디버깅하기 -브라우저 창의 개발자 콘솔은 랜더러 프로세스의 스크립트만 디버깅이 가능합니다. (다시말해 웹 페이지) -메인 프로세스의 디버깅 방법을 제공하기 위해 Electron은 `--debug` 과 `--debug-brk` 스위치들을 제공합니다. +브라우저 창의 개발자 콘솔은 웹 페이지 같은 랜더러 프로세스의 스크립트만 디버깅이 가능합니다. +대신 Electron은 메인 프로세스의 디버깅을 위해 `--debug` 과 `--debug-brk` 스위치들을 제공합니다. ## 커맨드 라인 스위치(command line switches) +다음 스위치들을 사용하여 Electron의 메인 프로세스를 디버깅 할 수 있습니다: + ### `--debug=[port]` -이 스위치를 사용하면 Electron은 지정한 `port`에 V8 디버거 프로토콜을 리스닝합니다. `port`는 `5858`이 기본적으로 사용됩니다. +이 스위치를 사용하면 Electron은 지정한 `port`에 V8 디버거 프로토콜을 리스닝합니다. 기본 `port`는 `5858` 입니다. ### `--debug-brk=[port]` @@ -15,8 +17,9 @@ ## node-inspector로 디버깅 하기 -__주의:__ Electron은 node v0.11.13 버전을 사용합니다. node-inspector는 현재 아주 잘 작동하지 않습니다. -그리고 메인 프로세스의 `process`를 node-inspector 콘솔 내에서 검사할 경우 크래시가 발생할 수 있습니다. +__참고:__ Electron은 node v0.11.13 버전을 사용합니다. +그리고 현재 node-inspector 유틸리티와 호환성 문제가 있습니다. +추가로 node-inspector 콘솔 내에서 메인 프로세스의 `process` 객체를 탐색할 경우 크래시가 발생할 수 있습니다. ### 1. [node-inspector][node-inspector] 서버 시작 diff --git a/docs-translations/ko/tutorial/desktop-environment-integration.md b/docs-translations/ko/tutorial/desktop-environment-integration.md index 50b142f0bda1..94f0ffa013a7 100644 --- a/docs-translations/ko/tutorial/desktop-environment-integration.md +++ b/docs-translations/ko/tutorial/desktop-environment-integration.md @@ -7,7 +7,7 @@ ## 최근 사용한 문서 (Windows & OS X) -Windows와 OS X는 dock menu나 JumpList등을 통하여 최근 문서 리스트에 쉽게 접근할 수 있습니다. +알다 싶이 Windows와 OS X는 JumpList 또는 dock 메뉴를 통해 최근 문서 리스트에 쉽게 접근할 수 있습니다. __JumpList:__ @@ -88,10 +88,10 @@ __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를 사용하여 구현할 수 있습니다: +사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] 메서드를 통해 구현할 수 있습니다: ```javascript var app = require('app'); @@ -166,7 +166,7 @@ win.setThumbarButtons([]); ## Unity 런처 숏컷 기능 (Linux) -Unity 환경에선 `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding shortcuts to a launcher][unity-launcher] 가이드를 참고하세요. +Unity 환경에선 `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding Shortcuts to a Launcher][unity-launcher] 가이드를 참고하세요. __Audacious의 런처 숏컷:__ diff --git a/docs-translations/ko/tutorial/devtools-extension.md b/docs-translations/ko/tutorial/devtools-extension.md index 81ebed413429..e6a9b559c35f 100644 --- a/docs-translations/ko/tutorial/devtools-extension.md +++ b/docs-translations/ko/tutorial/devtools-extension.md @@ -2,8 +2,8 @@ 어플리케이션의 디버깅을 쉽게 하기 위해 Electron은 기본적으로 [Chrome DevTools Extension][devtools-extension]을 지원합니다. -개발자 콘솔 확장기능은 간단하게 사용할 확장기능 플러그인의 소스코드를 다운로드한 후 `BrowserWindow.addDevToolsExtension` API를 이용하여 -어플리케이션 내에 로드할 수 있습니다. 한가지 주의할 점은 확장기능 사용시 창이 생성될 때 마다 일일이 해당 API를 호출할 필요는 없습니다. +개발자 콘솔 확장 기능은 간단하게 사용할 확장 기능 플러그인의 소스 코드를 다운로드한 후 `BrowserWindow.addDevToolsExtension` API를 이용하여 +어플리케이션 내에 로드할 수 있습니다. 한가지 주의할 점은 확장 기능 사용시 창이 생성될 때 마다 일일이 해당 API를 호출할 필요는 없습니다. 예시로 [React DevTools Extension](https://github.com/facebook/react-devtools)을 사용합니다. @@ -14,34 +14,34 @@ $ cd /some-directory $ git clone --recursive https://github.com/facebook/react-devtools.git ``` -그리고 개발자 콘솔이 열린 창에서 다음의 코드를 콘솔에 입력하면 확장기능을 로드할 수 있습니다: +그리고 개발자 콘솔이 열린 창에서 다음의 코드를 콘솔에 입력하면 확장 기능을 로드할 수 있습니다: ```javascript 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'); ``` -## 개발자 콘솔 확장기능의 구성 형식 +## 개발자 콘솔 확장 기능의 구성 형식 -완벽하게 모든 개발자 콘솔 확장은 Chrome 브라우저를 위해 작성되었기 때문에 Electron에서도 로드할 수 있습니다. -하지만 반드시 확장기능은 소스코드 그대로의 디렉터리(폴더) 형태여야 합니다. 그래서 `crx` 등의 포맷으로 패키징된 확장기능의 경우 -사용자가 직접 해당 패키지의 압축을 풀어서 로드하지 않는 이상은 Electron에서 해당 확장기능의 압축을 풀 방법이 없습니다. +모든 개발자 콘솔 확장은 완벽히 Chrome 브라우저를 위해 작성되었기 때문에 Electron에서도 로드할 수 있습니다. +하지만 반드시 확장 기능은 소스코드 그대로의 디렉터리(폴더) 형태여야 합니다. 그래서 `crx` 등의 포맷으로 패키징된 확장 기능의 경우 +사용자가 직접 해당 패키지의 압축을 풀어서 로드하지 않는 이상은 Electron에서 해당 확장 기능의 압축을 풀 방법이 없습니다. ## 백그라운드 페이지 현재 Electron은 Chrome에서 지원하는 백그라운드 페이지(background pages)를 지원하지 않습니다. -몇몇 확장기능은 이 기능에 의존하는 경우가 있는데 이 경우 해당 확장기능은 Electron에서 작동하지 않을 수 있습니다. +몇몇 확장 기능은 이 기능에 의존하는 경우가 있는데 이 경우 해당 확장 기능은 Electron에서 작동하지 않을 수 있습니다. ## `chrome.*` API -몇몇 Chrome 확장기능은 특정 기능을 사용하기 위해 `chrome.*` API를 사용하는데, Electron에선 이 API들을 구현하기 위해 노력했지만 안타깝게도 아직 모든 API가 구현되지는 않았습니다. +몇몇 Chrome 확장 기능은 특정 기능을 사용하기 위해 `chrome.*` API를 사용하는데, 이 API들을 구현하기 위해 노력했지만 안타깝게도 아직 모든 API가 구현되지는 않았습니다. -아직 모든 API가 구현되지 않았기 때문에 확장기능에서 `chrome.devtools.*` 대신 `chrome.*` API를 사용할 경우 확장기능이 제대로 작동하지 않을 수 있음을 감안해야 합니다. -만약 문제가 발생할 경우 Electron의 GitHub repo에 이슈를 올리면 해당 API를 추가하는데 많은 도움이 됩니다. +아직 모든 API가 구현되지 않았기 때문에 확장 기능에서 `chrome.devtools.*` 대신 `chrome.*` API를 사용할 경우 확장 기능이 제대로 작동하지 않을 수 있음을 감안해야 합니다. +만약 문제가 발생할 경우 Electron의 GitHub 저장소에 관련 이슈를 올리면 해당 API를 추가하는데 많은 도움이 됩니다. [devtools-extension]: https://developer.chrome.com/extensions/devtools diff --git a/docs-translations/ko/tutorial/online-offline-events.md b/docs-translations/ko/tutorial/online-offline-events.md index 3ccf20c7d568..57e0f48a3e0d 100644 --- a/docs-translations/ko/tutorial/online-offline-events.md +++ b/docs-translations/ko/tutorial/online-offline-events.md @@ -35,8 +35,8 @@ _online-status.html_ ``` -물론 필요하다면 이 이벤트를 메인 프로세스로 보낼 수도 있습니다. -하지만 메인 프로세스는 `navigator` 객체를 가지고 있지 않기 때문에 이 이벤트를 직접 사용할 수 없습니다. +메인 프로세스에서 이 이벤트를 처리할 필요가 있는 경우 이벤트를 메인 프로세스로 보낼 수 있습니다. +메인 프로세스는 `navigator` 객체를 가지고 있지 않기 때문에 이 이벤트를 직접 사용할 수 없습니다. 대신 다음 예제와 같이 Electron의 inter-process communication(ipc) 유틸리티를 사용하면 이벤트를 메인 프로세스로 전달할 수 있습니다. diff --git a/docs-translations/ko/tutorial/quick-start.md b/docs-translations/ko/tutorial/quick-start.md index 37b48d993342..4a642c253838 100644 --- a/docs-translations/ko/tutorial/quick-start.md +++ b/docs-translations/ko/tutorial/quick-start.md @@ -27,15 +27,14 @@ Electron 프로세스 내에서 작동하는 웹 페이지를 __랜더러 프로 `BrowserWindow` 인스턴스는 따로 분리된 프로세스에서 랜더링 되며 이 프로세스를 랜더러 프로세스라고 합니다. `BrowserWindow` 인스턴스가 소멸할 때 그 창의 랜더러 프로세스도 같이 소멸합니다. -메인 프로세스는 모든 웹 페이지와 랜더러 프로세스를 관리하며 -랜더러 프로세스는 각각의 프로세스에 고립되며 웹 페이지의 작동에만 영향을 끼칩니다. +메인 프로세스는 모든 웹 페이지와 랜더러 프로세스를 관리하며 랜더러 프로세스는 각각의 프로세스에 고립되며 웹 페이지의 작동에만 영향을 끼칩니다. -웹 페이지 내에서 네이티브 GUI 리소스를 관리하는 것은 보안에 취약하고 리소스를 누수시킬 수 있기 때문에 -기본적으로 웹 페이지 내에서는 네이티브 GUI와 관련된 API를 호출할 수 없도록 되어 있습니다. -만약 웹 페이지 내에서 GUI작업이 필요하다면 메인 프로세스에서 그 작업을 할 수 있도록 메인 프로세스와 통신을 해야합니다. +웹 페이지 내에선 기본적으로 네이티브 GUI와 관련된 API를 호출할 수 없도록 설계 되어 있습니다. +왜냐하면 웹 페이지 내에서 네이티브 GUI 리소스를 관리하는 것은 보안에 취약하고 리소스를 누수시킬 수 있기 때문입니다. +꼭 웹 페이지 내에서 API를 사용해야 한다면 메인 프로세스에서 그 작업을 처리할 수 있도록 메인 프로세스와 통신을 해야 합니다. -Electron에는 메인 프로세스와 랜더러 프로세스간에 통신을 할 수 있도록 [ipc](../api/ipc-renderer.md) 모듈을 제공하고 있습니다. -또한 [remote](../api/remote.md) 모듈을 사용하여 RPC 스타일로 통신할 수도 있습니다. +Electron에는 메인 프로세스와 랜더러 프로세스 사이에 통신을 할 수 있도록 [ipc](../api/ipc-renderer.md) 모듈을 제공하고 있습니다. +또는 [remote](../api/remote.md) 모듈을 사용하여 RPC 스타일로 통신할 수도 있습니다. ## 첫번째 Electron 앱 만들기 @@ -49,7 +48,7 @@ your-app/ ``` `package.json`은 node 모듈의 package.json과 같습니다. -그리고 `main` 필드에 스크립트 파일을 집어넣어 메인 프로세스로 사용할 엔트리 포인트를 지정할 수 있습니다. +그리고 `main` 필드에 스크립트 파일을 지정하면 메인 프로세스의 엔트리 포인트로 사용합니다. 예를 들어 사용할 수 있는 `package.json`은 다음과 같습니다: ```json @@ -176,4 +175,4 @@ $ ./Electron.app/Contents/MacOS/Electron your-app/ ### 배포용 파일 만들기 -어플리케이션 작성을 완료했다면 [어플리케이션 배포](application-distribution.md) 가이드를 통해 본격적으로 제작한 앱을 배포할 수 있습니다. \ No newline at end of file +어플리케이션 작성을 완료했다면 [어플리케이션 배포](application-distribution.md) 가이드를 통해 제작한 앱을 본격적으로 배포할 수 있습니다. \ No newline at end of file diff --git a/docs-translations/ko/tutorial/using-native-node-modules.md b/docs-translations/ko/tutorial/using-native-node-modules.md index 4584ebd460fe..f9cb2be3bf53 100644 --- a/docs-translations/ko/tutorial/using-native-node-modules.md +++ b/docs-translations/ko/tutorial/using-native-node-modules.md @@ -6,7 +6,7 @@ Electron에선 node.js 네이티브 모듈이 지원됩니다. 하지만 Electro ## 네이티브 node 모듈 호환성 Node v0.11.x 버전부터는 V8 API의 중대한 변경이 있었습니다. 하지만 대부분의 네이티브 모듈은 Node v0.10.x 버전을 타겟으로 작성 되었기 때문에 -새로운 Node 또는 io.js 버전에서 작동하지 않을 수 있습니다. Electron은 내부적으로 __io.js v3.1.0__ 버전을 사용하기 때문에 이러한 호환성 문제가 발생할 수 있습니다. +새로운 Node 또는 io.js 버전에서 작동하지 않을 수 있습니다. Electron은 내부적으로 __io.js v3.1.0__ 버전을 사용하기 때문에 호환성 문제가 발생할 수 있습니다. 이 문제를 해결하기 위해선 모듈이 v0.11.x 또는 최신 버전을 지원할 수 있도록 변경해야 합니다. 현재 [많은 모듈들](https://www.npmjs.org/browse/depended/nan)이 안정적으로 두 버전 모두 지원하고 있지만 오래된 모듈의 경우 여전히 Node v0.10.x 버전만을 지원하고 있습니다. @@ -14,6 +14,8 @@ Node v0.11.x 버전부터는 V8 API의 중대한 변경이 있었습니다. 하 ## 네이티브 모듈 설치하는 방법 +네이티브 모듈을 설치하는 방법은 세 가지 종류가 있습니다. + ### 쉬운 방법 [`electron-rebuild`](https://github.com/paulcbetts/electron-rebuild) 패키지를 사용하면 빠르고 간단하게 네이티브 모듈을 다시 빌드할 수 있습니다. @@ -22,7 +24,7 @@ Node v0.11.x 버전부터는 V8 API의 중대한 변경이 있었습니다. 하 ```sh npm install --save-dev electron-rebuild -# 필요한 네이티브 모듈을 `npm install`로 설치한 후 다음 작업을 실행하세요: +# 필요한 네이티브 모듈을 `npm install`로 설치한 후 다음 명령을 실행하세요: ./node_modules/.bin/electron-rebuild ``` diff --git a/docs-translations/ko/tutorial/using-pepper-flash-plugin.md b/docs-translations/ko/tutorial/using-pepper-flash-plugin.md index 4577bc296fea..f47f20d8a71e 100644 --- a/docs-translations/ko/tutorial/using-pepper-flash-plugin.md +++ b/docs-translations/ko/tutorial/using-pepper-flash-plugin.md @@ -1,7 +1,7 @@ # Pepper 플래시 플러그인 사용하기 -작업에 필요한 경우 pepper 플래시 플러그인을 사용할 수 있습니다. -Electron에서 pepper 플래시 플러그인을 사용하기 위해선 따로 pepper 플래시 플러그인의 위치를 지정해 주어야합니다. +Electron은 Pepper 플래시 플러그인을 지원합니다. +Pepper 플래시 플러그인을 사용하려면 Pepper 플래시 플러그인의 위치를 지정해야 합니다. ## 플래시 플러그인 준비하기 @@ -10,7 +10,7 @@ Electron에서 플래시 플러그인을 지원하기 위해선 이 두 가지 ## Electron 스위치 추가 -플러그인을 사용하기 위해 직접적으로 `--ppapi-flash-path` 와 `ppapi-flash-version` 플래그를 ready 이벤트가 호출되기 전에 추가해야합니다. +플러그인을 사용하려면 Electron 커맨드 라인에 `--ppapi-flash-path` 와 `ppapi-flash-version` 플래그를 app의 ready 이벤트가 호출되기 전에 추가해야 합니다. 그리고 `browser-window`에 `plugins` 스위치도 추가해야합니다. ```javascript @@ -20,8 +20,6 @@ var BrowserWindow = require('browser-window'); // Report crashes to our server. require('crash-reporter').start(); -// Keep a global reference of the window object, if you don't, the window will -// be closed automatically when the javascript object is GCed. var mainWindow = null; // Quit when all windows are closed. @@ -54,7 +52,9 @@ app.on('ready', function() { ``` ## `` 태그를 이용하여 플러그인을 활성화 + `plugins` 속성을 `` 태그에 추가합니다. + ```html ``` diff --git a/docs-translations/ko/tutorial/using-selenium-and-webdriver.md b/docs-translations/ko/tutorial/using-selenium-and-webdriver.md index a29e8e2214ef..33dc6311ce35 100644 --- a/docs-translations/ko/tutorial/using-selenium-and-webdriver.md +++ b/docs-translations/ko/tutorial/using-selenium-and-webdriver.md @@ -7,13 +7,13 @@ > ChromeDriver는 Chromium의 WebDriver wire 프로토콜 스텐드얼론 서버 구현입니다. > Chromium 과 WebDriver 팀 멤버에 의해 개발되었습니다. -Electron과 `chromedriver`를 같이 사옹하려면 드라이버에서 Electron을 찾을 수 있도록 해야 하고 +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. 크롬 드라이버 시작 @@ -25,7 +25,7 @@ Starting ChromeDriver (v2.10.291558) on port 9515 Only local connections are allowed. ``` -포트 `9515`는 나중에 사용하므로 기억해 놓읍시다 +포트 `9515`는 나중에 사용하므로 기억해 놓습니다. ### 2. WebDriverJS 설치 @@ -35,7 +35,7 @@ $ npm install selenium-webdriver ### 3. 크롬 드라이버에 연결 -`selenium-webdriver`를 Electron과 같이 사용할 땐 기본적으로 upstream과 같습니다. +`selenium-webdriver`를 Electron과 같이 사용하는 방법은 기본적으로 upstream과 같습니다. 한가지 다른점이 있다면 수동으로 크롬 드라이버 연결에 대해 설정하고 Electron 실행파일의 위치를 전달합니다: ```javascript @@ -45,7 +45,7 @@ var driver = new webdriver.Builder() // 작동하고 있는 크롬 드라이버의 포트 "9515"를 사용합니다. .usingServer('http://localhost:9515') .withCapabilities({chromeOptions: { - // 여기에 사용중인 Electron 바이너리의 경로를 기재하세요. + // 여기에 사용중인 Electron 바이너리의 경로를 지정하세요. binary: '/Path-to-Your-App.app/Contents/MacOS/Atom'}}) .forBrowser('electron') .build(); @@ -88,11 +88,11 @@ $ npm install webdriverio ```javascript var webdriverio = require('webdriverio'); var options = { - host: "localhost", // Use localhost as chrome driver server - port: 9515, // "9515" is the port opened by chrome driver. + host: "localhost", // localhost에서 작동중인 크롬 드라이버 서버를 사용합니다. + port: 9515, // 연결할 크롬 드라이버 서버의 포트를 설정합니다. desiredCapabilities: { browserName: 'chrome', - chromeOptions: {binary: '/Path-to-Your-App.app/Electron'} // Path to your Electron binary. + chromeOptions: {binary: '/Path-to-Your-App.app/Electron'} // Electron 바이너리의 위치 } };