From eca98b85fcbabcca9ccb265287cf665da830753f Mon Sep 17 00:00:00 2001 From: Plusb Preco Date: Fri, 20 Nov 2015 02:25:44 +0900 Subject: [PATCH] Cleanup docs, fix typos --- README-ko.md | 20 +-- .../ko-KR/development/atom-shell-vs-node-webkit.md | 19 ++- .../ko-KR/development/build-instructions-linux.md | 31 +++-- .../ko-KR/development/build-instructions-osx.md | 10 +- .../development/build-instructions-windows.md | 42 +++---- .../ko-KR/development/build-system-overview.md | 28 ++--- .../ko-KR/development/coding-style.md | 36 +++--- .../ko-KR/development/setting-up-symbol-server.md | 40 +++--- .../development/source-code-directory-structure.md | 31 +++-- docs-translations/ko-KR/styleguide.md | 23 ++-- .../ko-KR/tutorial/application-distribution.md | 59 +++++---- .../ko-KR/tutorial/application-packaging.md | 61 +++++---- .../ko-KR/tutorial/debugging-main-process.md | 17 +-- .../tutorial/desktop-environment-integration.md | 138 +++++++++++++-------- .../ko-KR/tutorial/devtools-extension.md | 42 ++++--- .../tutorial/mac-app-store-submission-guide.md | 39 +++--- .../ko-KR/tutorial/online-offline-events.md | 11 +- docs-translations/ko-KR/tutorial/quick-start.md | 70 +++++++---- .../ko-KR/tutorial/supported-platforms.md | 16 ++- .../ko-KR/tutorial/using-native-node-modules.md | 35 ++++-- .../ko-KR/tutorial/using-pepper-flash-plugin.md | 8 +- .../ko-KR/tutorial/using-selenium-and-webdriver.md | 33 ++--- 22 files changed, 466 insertions(+), 343 deletions(-) diff --git a/README-ko.md b/README-ko.md index d35ba87..606d4e9 100644 --- a/README-ko.md +++ b/README-ko.md @@ -8,8 +8,8 @@ :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)에 사용되고 있습니다. @@ -17,17 +17,17 @@ Electron에 대한 중요한 알림을 받고 싶다면 Twitter에서 [@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 바이너리를 -설치할 수도 있습니다: +또한 [`npm`](https://docs.npmjs.com/)을 통해 미리 빌드된 Electron 바이너리를 설치할 +수도 있습니다: ```sh # $PATH에 `electron` 커맨드를 등록하고 전역에 설치합니다. @@ -70,5 +70,5 @@ API 레퍼런스가 있습니다. Electron을 빌드 하는 방법과 프로젝 - Slack의 [`Atom`](http://atom-slack.herokuapp.com/) 채널 [awesome-electron](https://github.com/sindresorhus/awesome-electron) 프로젝트에 -커뮤니티가 운영중인 유용한 예제 어플리케이션과 도구, 리소스가 있으니 -한번 참고해 보시기 바랍니다. +커뮤니티가 운영중인 유용한 예제 어플리케이션과 도구, 리소스가 있으니 한번 참고해 보시기 +바랍니다. diff --git a/docs-translations/ko-KR/development/atom-shell-vs-node-webkit.md b/docs-translations/ko-KR/development/atom-shell-vs-node-webkit.md index e7dd017..22e8e37 100644 --- a/docs-translations/ko-KR/development/atom-shell-vs-node-webkit.md +++ b/docs-translations/ko-KR/development/atom-shell-vs-node-webkit.md @@ -2,17 +2,17 @@ __참고: 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을 지정하면 -어플리케이션의 메인 윈도우로 열리게 됩니다. +NW.js에선 어플리케이션의 엔트리 포인트로 웹 페이지를 사용합니다. `package.json`내의 +main 필드에 메인 웹 페이지(index.html) URL을 지정하면 어플리케이션의 메인 윈도우로 +열리게 됩니다. Electron에선 JavaScript를 엔트리 포인트로 사용합니다. URL을 직접 제공하는 대신 API를 사용하여 직접 브라우저 창과 HTML 파일을 로드할 수 있습니다. 또한 윈도우의 종료시기를 @@ -31,11 +31,10 @@ Chromium Content 모듈과 종속성 라이브러리들을 포함합니다. 유 __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. 다중 컨텍스트__ diff --git a/docs-translations/ko-KR/development/build-instructions-linux.md b/docs-translations/ko-KR/development/build-instructions-linux.md index 7a6a476..c4f161f 100644 --- a/docs-translations/ko-KR/development/build-instructions-linux.md +++ b/docs-translations/ko-KR/development/build-instructions-linux.md @@ -38,8 +38,8 @@ $ sudo yum install clang dbus-devel gtk2-devel libnotify-devel libgnome-keyring- ## 가상머신을 사용하여 빌드 하는 경우 -만약 Electron을 가상머신으로 빌드 할 계획이라면 해당 가상머신의 스토리지를 -최소 25GB 이상을 확보해 놓아야 합니다. +만약 Electron을 가상머신으로 빌드 할 계획이라면 해당 가상머신의 스토리지를 최소 25GB +이상 확보해 놓아야 합니다. ## 코드 가져오기 @@ -49,11 +49,10 @@ $ git clone https://github.com/atom/electron.git ## 부트 스트랩 -부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 -프로젝트 파일을 생성합니다. 스크립트가 정상적으로 작동하기 위해선 -Python 2.7.x 버전이 필요합니다. 아마 다운로드 작업이 상당히 많은 시간을 -소요할 것입니다. 참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 -`Makefile`은 생성되지 않습니다. +부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 +파일을 생성합니다. 스크립트가 정상적으로 작동하기 위해선 Python 2.7.x 버전이 +필요합니다. 아마 다운로드 작업이 상당히 많은 시간을 소요할 것입니다. 참고로 Electron은 +`ninja`를 빌드 툴체인으로 사용하므로 `Makefile`은 생성되지 않습니다. ```bash $ cd electron @@ -84,18 +83,18 @@ $ ./script/bootstrap.py -v --target_arch=arm $ ./script/build.py ``` -이 스크립트는 `out/R` 디렉터리에 크기가 매우 큰 Electron 실행 파일을 배치합니다. -파일 크기는 1.3GB를 초과합니다. 이러한 문제가 발생하는 이유는 Release 타겟 바이너리가 -디버그 심볼을 포함하기 때문입니다. 파일 크기를 줄이려면 -`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` 타겟만 빌드 할 수 있습니다: @@ -119,8 +118,8 @@ $ ./script/clean.py ## 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 diff --git a/docs-translations/ko-KR/development/build-instructions-osx.md b/docs-translations/ko-KR/development/build-instructions-osx.md index 222d4fc..9e2a76d 100644 --- a/docs-translations/ko-KR/development/build-instructions-osx.md +++ b/docs-translations/ko-KR/development/build-instructions-osx.md @@ -20,9 +20,9 @@ $ git clone https://github.com/atom/electron.git ## 부트 스트랩 -부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 -프로젝트 파일을 생성합니다. 참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 -Xcode 프로젝트는 생성되지 않습니다. +부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 +파일을 생성합니다. 참고로 Electron은 `ninja`를 빌드 툴체인으로 사용하므로 Xcode +프로젝트는 생성되지 않습니다. ```bash $ cd electron @@ -47,8 +47,8 @@ $ ./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-KR/development/build-instructions-windows.md b/docs-translations/ko-KR/development/build-instructions-windows.md index 69811ac..13bbf47 100644 --- a/docs-translations/ko-KR/development/build-instructions-windows.md +++ b/docs-translations/ko-KR/development/build-instructions-windows.md @@ -11,18 +11,18 @@ * [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** 을 사용하고 있는지 +확인해주세요. ## 코드 가져오기 @@ -32,9 +32,9 @@ $ git clone https://github.com/atom/electron.git ## 부트 스트랩 -부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 -프로젝트 파일을 생성합니다. 참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 -Visual Studio 프로젝트는 생성되지 않습니다. +부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 +파일을 생성합니다. 참고로 Electron은 `ninja`를 빌드 툴체인으로 사용하므로 Visual +Studio 프로젝트는 생성되지 않습니다. ```powershell $ cd electron @@ -60,8 +60,8 @@ $ python script\build.py -c D ## 64비트 빌드 -64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때 -`--target_arch=x64` 인자를 같이 넘겨주면 됩니다: +64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때 `--target_arch=x64` +인자를 같이 넘겨주면 됩니다: ```powershell $ python script\bootstrap.py -v --target_arch=x64 @@ -83,8 +83,8 @@ $ python script\cpplint.py $ python script\test.py ``` -테스트 실행시 `runas`와 같은 네이티브 모듈을 포함하는데 이 모듈은 디버그 빌드에서 -같이 사용할 수 없습니다. 하지만 여전히 릴리즈 빌드에선 사용할 수 있습니다. +테스트 실행시 `runas`와 같은 네이티브 모듈을 포함하는데 이 모듈은 디버그 빌드에서 같이 +사용할 수 없습니다. 하지만 여전히 릴리즈 빌드에선 사용할 수 있습니다. 릴리즈 빌드로 테스트를 실행하려면 다음 커맨드를 사용하면 됩니다: @@ -105,8 +105,8 @@ Visual Studio가 업데이트까지 완벽하게 설치된 최신버전인지 ### Assertion failed: ((handle))->activecnt >= 0 -Cygwin에서 빌드 할 경우 `bootstrap.py` 스크립트가 다음의 에러와 함께 빌드에 -실패할 수 있습니다: +Cygwin에서 빌드 할 경우 `bootstrap.py` 스크립트가 다음의 에러와 함께 빌드에 실패할 수 +있습니다: ``` Assertion failed: ((handle))->activecnt >= 0, file src\win\pipe.c, line 1430 @@ -123,9 +123,9 @@ 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 diff --git a/docs-translations/ko-KR/development/build-system-overview.md b/docs-translations/ko-KR/development/build-system-overview.md index 0c35d04..71002ff 100644 --- a/docs-translations/ko-KR/development/build-system-overview.md +++ b/docs-translations/ko-KR/development/build-system-overview.md @@ -9,17 +9,17 @@ Electron을 빌드 할 때 `gyp` 파일들은 다음과 같은 규칙을 따릅 * `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" 방식을 도입했습니다. 이는 각각의 컴포넌트를 -각각 따로 분리하여 공유 라이브러리로 빌드 합니다. 하지만 이 빌드 방식을 사용하면 -링킹 작업은 매우 빨라지지만 실행 파일 크기가 커지고 성능이 저하됩니다. +위해 Chromium의 "component build" 방식을 도입했습니다. 이는 각각의 컴포넌트를 각각 +따로 분리하여 공유 라이브러리로 빌드 합니다. 하지만 이 빌드 방식을 사용하면 링킹 작업은 +매우 빨라지지만 실행 파일 크기가 커지고 성능이 저하됩니다. Electron도 이러한 방식에 상당히 비슷한 접근을 했습니다: `Debug` 빌드 시 바이너리는 공유 라이브러리 버전의 Chromium 컴포넌트를 사용함으로써 @@ -33,15 +33,15 @@ Prebuilt된 모든 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 @@ -55,15 +55,15 @@ Electron은 `Release`와 `Debug` 빌드가 서로 다른 라이브러리 링크 지원하지 않습니다. 이 문제를 해결하기 위해 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 하기 위해 빌드 하는 것이라면 이 문제에 신경 쓸 필요가 없습니다. diff --git a/docs-translations/ko-KR/development/coding-style.md b/docs-translations/ko-KR/development/coding-style.md index 0dc16ba..21ee03f 100644 --- a/docs-translations/ko-KR/development/coding-style.md +++ b/docs-translations/ko-KR/development/coding-style.md @@ -4,29 +4,35 @@ ## 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)가 +진행되고 있습니다. diff --git a/docs-translations/ko-KR/development/setting-up-symbol-server.md b/docs-translations/ko-KR/development/setting-up-symbol-server.md index ed43e0f..bfd347a 100644 --- a/docs-translations/ko-KR/development/setting-up-symbol-server.md +++ b/docs-translations/ko-KR/development/setting-up-symbol-server.md @@ -1,29 +1,36 @@ # 디버거에서 디버그 심볼 서버 설정 -디버그 심볼은 디버깅 세션을 더 좋게 개선해 줍니다. 디버그 심볼은 실행 파일과 동적 링크 라이브러리에서 메서드에 대한 정보를 담고 있으며 명료한 함수 호출 스텍 정보를 제공합니다. -심볼 서버는 유저가 크기가 큰 디버깅용 파일을 필수적으로 다운로드 받지 않고도 디버거가 알맞은 심볼, 바이너리 그리고 소스를 자동적으로 로드할 수 있도록 해줍니다. -서버 사용법은 [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 @@ -36,7 +43,8 @@ SRV*c:\code\symbols\*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symb ## 문제 해결: Symbols will not load -Windbg에서 다음의 커맨드를 입력하여 왜 심볼이 로드되지 않았는지에 대한 오류 내역을 출력합니다: +Windbg에서 다음의 커맨드를 입력하여 왜 심볼이 로드되지 않았는지에 대한 오류 내역을 +출력합니다: ``` > !sym noisy diff --git a/docs-translations/ko-KR/development/source-code-directory-structure.md b/docs-translations/ko-KR/development/source-code-directory-structure.md index f31d084..e0e172d 100644 --- a/docs-translations/ko-KR/development/source-code-directory-structure.md +++ b/docs-translations/ko-KR/development/source-code-directory-structure.md @@ -1,8 +1,10 @@ # 소스 코드 디렉터리 구조 -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)에 +익숙해져 있다면 소스 코드를 이해하기 쉬울 것입니다. ## 소스 코드 구조 @@ -10,8 +12,8 @@ Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 그 Electron ├──atom - Electron의 소스코드. | ├── app - 시스템 엔트리 코드. -| ├── browser - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것들. -| | | 랜더러와 웹 페이지 관리 관련 코드. +| ├── browser - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것과 +| | 랜더러와 웹 페이지 관리 관련 코드. | | ├── lib - 메인 프로세스 초기화 코드의 자바스크립트 파트. | | ├── ui - 크로스 플랫폼에 대응하는 UI 구현. | | | ├── cocoa - 코코아 특정 소스 코드. @@ -27,8 +29,8 @@ Electron | | ├── lib - 랜더러 프로세스 초기화 코드의 자바스크립트 파트. | | └── api - 랜더러 프로세스 API들의 구현. | | └── lib - API 구현의 자바스크립트 파트. -| └── common - 메인 프로세스와 랜더러 프로세스에서 공유하는 코드. -| | 유틸리티 함수와 node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드도 포함. +| └── common - 메인 프로세스와 랜더러 프로세스에서 공유하는 코드. 유틸리티 함수와 +| node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드도 포함. | ├── lib - 공통 자바스크립트 초기화 코드. | └── api - 공통 API들의 구현, Electron의 빌트인 모듈 기초 코드들. | └── lib - API 구현의 자바스크립트 파트. @@ -36,16 +38,21 @@ Electron ├── 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` 빌드를 지원하지 않아 따로 다운로드된 서드파티 + 프레임워크 바이너리들. diff --git a/docs-translations/ko-KR/styleguide.md b/docs-translations/ko-KR/styleguide.md index 7318c7e..dd02629 100644 --- a/docs-translations/ko-KR/styleguide.md +++ b/docs-translations/ko-KR/styleguide.md @@ -11,15 +11,15 @@ Electron 문서를 작성하는 규칙은 다음과 같습니다. - `h1` 제목은 페이지당 한 개만 사용할 수 있습니다. - 코드 블럭에서 터미널 언어 선택시 `cmd` 대신 `bash`를 사용합니다. (syntax highlighter를 사용하기 위해서) -- 문서의 `h1` 제목은 반드시 현재 객체 이름과 같게 해야 합니다. - (예시: `browser-window` → `BrowserWindow`) +- 문서의 `h1` 제목은 반드시 현재 객체 이름과 같게 해야 합니다. (`browser-window` → + `BrowserWindow`) - 하이픈(-)으로 구분되었건 다르게 구분되었건 예시와 같이 작성합니다. -- 헤더 밑에 헤더를 바로 사용하지 않습니다. 한 줄이라도 좋으니 헤더와 헤더 사이에 - 설명을 추가합니다. +- 헤더 밑에 헤더를 바로 사용하지 않습니다. 한 줄이라도 좋으니 헤더와 헤더 사이에 설명을 + 추가합니다. - 메서드 헤더는 `code backtick` 으로 표시합니다. - 이벤트 헤더는 한 '따옴표'로 표시합니다. -- 리스트를 2 단계 이상 중첩하지 않습니다. (안타깝게도 markdown 랜더러가 이를 - 지원하지 않습니다) +- 리스트를 2 단계 이상 중첩하지 않습니다. (안타깝게도 markdown 랜더러가 이를 지원하지 + 않습니다) - 섹션에 대한 제목을 추가합니다. Events, Class 메서드 그리고 인스턴스 메서드 등 - 어떤 '것'의 사용 결과를 설명할 때 '될 것입니다' 형식을 사용하여 설명합니다. - 이벤트와 메서드를 표기할 땐 `h3` 헤더를 사용합니다. @@ -37,8 +37,8 @@ Electron 문서를 작성하는 규칙은 다음과 같습니다. 아직 번역되지 않은 언어를 추가하려면 (일부분 포함): - 언어의 약어(예: en-US, ja-JP, ko-KR)로 서브 디렉터리를 만듭니다. -- 서브 디렉터리에 `docs` 디렉터리를 복사합니다. 파일 이름과 디렉터리 구조는 - 모두 유지합니다. +- 서브 디렉터리에 `docs` 디렉터리를 복사합니다. 파일 이름과 디렉터리 구조는 모두 + 유지합니다. - 문서를 번역합니다. - 언어 디렉터리 내의 `README.md`에 번역한 문서의 링크를 추가합니다. - 메인(upstream) Electron의 [README](https://github.com/atom/electron#documentation-translations)에 @@ -65,14 +65,13 @@ Electron 문서 구조를 이해하는 데 참고할 수 있는 유용한 도움 메서드 이름은 인수가 무엇을 받는지에 따라 결정됩니다. 선택적 인수는 브라켓([, ])으로 묶어 이 인수가 다른 인수뒤에서 선택적으로 사용될 수 있다는 것을 표시합니다. -메서드 이름 하단에선 각 인수에 대해 자세한 설명을 합니다. -인수의 타입은 일반적인 타입 중 하나를 받거나: +메서드 이름 하단에선 각 인수에 대해 자세한 설명을 합니다. 인수의 타입은: [`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 diff --git a/docs-translations/ko-KR/tutorial/application-distribution.md b/docs-translations/ko-KR/tutorial/application-distribution.md index 6926950..73839f2 100644 --- a/docs-translations/ko-KR/tutorial/application-distribution.md +++ b/docs-translations/ko-KR/tutorial/application-distribution.md @@ -2,10 +2,9 @@ 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의 경우: @@ -16,7 +15,7 @@ electron/Electron.app/Contents/Resources/app/ └── index.html ``` -Windows 와 Linux의 경우: +Windows와 Linux의 경우: ```text electron/resources/app @@ -25,16 +24,18 @@ 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) +아카이브를 통해 어플리케이션의 소스코드가 사용자에게 노출되는 것을 방지할 수 있습니다. -`asar` 아카이브를 사용할 땐 단순히 `app` 폴더 대신에 어플리케이션을 패키징한 `app.asar` 파일로 대체하면됩니다. -Electron은 자동으로 `app`폴더 대신 asar 아카이브를 기반으로 어플리케이션을 실행합니다. +`asar` 아카이브를 사용할 땐 단순히 `app` 폴더 대신에 어플리케이션을 패키징한 +`app.asar` 파일로 대체하면됩니다. Electron은 자동으로 `app`폴더 대신 asar 아카이브를 +기반으로 어플리케이션을 실행합니다. OS X의 경우: @@ -59,22 +60,25 @@ electron/resources/ ### 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`을 원하는 +아이콘으로 변경하면 됩니다. -원하는 이름으로 바꾼 어플리케이션 예제: +어플리케이션 이름을 원하는 이름으로 변경한 예시: ``` MyApp.app/Contents @@ -98,13 +102,14 @@ 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) @@ -135,7 +140,9 @@ $ script/build.py -c Release -t myapp ### 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 모듈 또한 새로운 실행파일 이름으로 일치시킵니다. diff --git a/docs-translations/ko-KR/tutorial/application-packaging.md b/docs-translations/ko-KR/tutorial/application-packaging.md index 9a5e3df..a04dfeb 100644 --- a/docs-translations/ko-KR/tutorial/application-packaging.md +++ b/docs-translations/ko-KR/tutorial/application-packaging.md @@ -1,7 +1,8 @@ # 어플리케이션 패키징 -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` 아카이브 생성 @@ -24,13 +25,15 @@ $ asar pack your-app app.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`라는 아카이브가 있다고 가정하면: @@ -90,9 +93,10 @@ $.get('file:///path/to/example.asar/file.txt', function(data) { ### `asar` 아카이브를 일반 파일로 취급하기 -`asar` 아카이브의 체크섬(checksum)을 검사하는 작업등을 하기 위해선 `asar` 아카이브를 파일 그대로 읽어야 합니다. -이러한 작업을 하기 위해 `original-fs` 빌트인 모듈을 `fs` 모듈 대신에 사용할 수 있습니다. -이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를 읽어들입니다: +`asar` 아카이브의 체크섬(checksum)을 검사하는 작업등을 하기 위해선 `asar` 아카이브를 +파일 그대로 읽어야 합니다. 이러한 작업을 하기 위해 `original-fs` 빌트인 모듈을 `fs` +모듈 대신에 사용할 수 있습니다. 이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를 +읽어들입니다: ```javascript var originalFs = require('original-fs'); @@ -101,22 +105,26 @@ originalFs.readFileSync('/path/to/example.asar'); ## 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 메서드는 다음과 같습니다: @@ -127,24 +135,27 @@ originalFs.readFileSync('/path/to/example.asar'); ### `fs.stat`의 잘못된 스테이터스 정보 -`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 예측된 디렉터리 파일 정보를 가집니다. -왜냐하면 아카이브의 디렉터리 경로는 실제 파일시스템에 존재하지 않기 때문입니다. -그러한 이유로 파일 크기와 파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다. +`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 +할 경우 예측된 디렉터리 파일 정보를 가집니다. 왜냐하면 아카이브의 디렉터리 경로는 실제 +파일 시스템에 존재하지 않기 때문입니다. 그러한 이유로 파일 크기와 +파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다. ## `asar` 아카이브에 미리 압축 해제된 파일 추가하기 전술한 바와 같이 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다. -이 방법은 성능문제가 발생할 수 있습니다. 그리고 설계상 백신 소프트웨어에서 잘못 진단하여 바이러스로 판단 할 수도 있습니다. +이 방법은 성능문제가 발생할 수 있습니다. 그리고 설계상 백신 소프트웨어에서 잘못 진단하여 +바이러스로 진단 할 수도 있습니다. -이 문제를 해결하려면 `--unpack` 옵션을 활용하여 파일을 압축이 풀려진 상태로 유지해야 합니다. -다음의 예제는 node 네이티브 모듈의 공유 라이브러리를 unpack 상태로 유지합니다: +이 문제를 해결하려면 `--unpack` 옵션을 통해 파일을 압축이 풀려진 상태로 유지해야 합니다. +다음의 예제는 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 diff --git a/docs-translations/ko-KR/tutorial/debugging-main-process.md b/docs-translations/ko-KR/tutorial/debugging-main-process.md index b03e254..32a6bd0 100644 --- a/docs-translations/ko-KR/tutorial/debugging-main-process.md +++ b/docs-translations/ko-KR/tutorial/debugging-main-process.md @@ -1,7 +1,8 @@ # 메인 프로세스 디버깅하기 -브라우저 창의 개발자 도구는 웹 페이지 같은 랜더러 프로세스의 스크립트만 디버깅이 가능합니다. -대신 Electron은 메인 프로세스의 디버깅을 위해 `--debug` 과 `--debug-brk` 스위치들을 제공합니다. +브라우저 창의 개발자 도구는 웹 페이지 같은 랜더러 프로세스의 스크립트만 디버깅이 +가능합니다. 대신 Electron은 메인 프로세스의 디버깅을 위해 `--debug` 과 `--debug-brk` +스위치들을 제공합니다. ## 커맨드 라인 스위치(command line switches) @@ -9,7 +10,8 @@ ### `--debug=[port]` -이 스위치를 사용하면 Electron은 지정한 `port`에 V8 디버거 프로토콜을 리스닝합니다. 기본 `port`는 `5858` 입니다. +이 스위치를 사용하면 Electron은 지정한 `port`에 V8 디버거 프로토콜을 리스닝합니다. +기본 `port`는 `5858` 입니다. ### `--debug-brk=[port]` @@ -17,9 +19,9 @@ ## 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] 서버 시작 @@ -43,6 +45,7 @@ $ electron --debug-brk=5858 your/app ### 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 diff --git a/docs-translations/ko-KR/tutorial/desktop-environment-integration.md b/docs-translations/ko-KR/tutorial/desktop-environment-integration.md index 433a6d5..1dc5f66 100644 --- a/docs-translations/ko-KR/tutorial/desktop-environment-integration.md +++ b/docs-translations/ko-KR/tutorial/desktop-environment-integration.md @@ -1,15 +1,18 @@ # 데스크톱 환경 통합 -어플리케이션 배포의 대상이 되는 서로 다른 운영체제 시스템의 환경에 맞춰 어플리케이션의 기능을 통합할 수 있습니다. -예를 들어 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', { @@ -21,17 +24,21 @@ myNotification.onclick = function () { } ``` -위 코드를 통해 생성한 데스크톱 알림은 각 운영체제 모두 비슷한 사용자 경험을 제공합니다. 하지만 몇 가지 다른 점들이 있습니다. +위 코드를 통해 생성한 데스크톱 알림은 각 운영체제 모두 비슷한 사용자 경험을 제공합니다. +하지만 몇 가지 다른 점들이 있습니다. ### 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', { @@ -40,12 +47,14 @@ 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 @@ -53,11 +62,13 @@ 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:__ @@ -67,13 +78,15 @@ __어플리케이션 dock menu:__ -파일을 최근 문서에 추가하려면 [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(); @@ -81,11 +94,13 @@ app.clearRecentDocuments(); ### Windows에서 주의할 점 -이 기능을 Windows에서 사용할 땐 운영체제 시스템에 어플리케이션에서 사용하는 파일 확장자가 등록되어 있어야 합니다. -그렇지 않은 경우 파일을 JumpList에 추가해도 추가되지 않습니다. -어플리케이션 등록에 관련된 API의 모든 내용은 [Application Registration][app-registration]에서 찾아볼 수 있습니다. +이 기능을 Windows에서 사용할 땐 운영체제 시스템에 어플리케이션에서 사용하는 파일 +확장자가 등록되어 있어야 합니다. 그렇지 않은 경우 파일을 JumpList에 추가해도 추가되지 +않습니다. 어플리케이션 등록에 관련된 API의 모든 내용은 [Application Registration][app-registration]에서 +찾아볼 수 있습니다. -유저가 JumpList에서 파일을 클릭할 경우 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어 새로운 인스턴스의 어플리케이션이 실행됩니다. +유저가 JumpList에서 파일을 클릭할 경우 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어 +새로운 인스턴스의 어플리케이션이 실행됩니다. ### OS X에서 주의할 점 @@ -100,7 +115,8 @@ __Terminal.app의 dock menu:__ -커스텀 dock menu를 설정하려면 `app.dock.setMenu` API를 사용하면 됩니다. OS X에서만 사용 가능합니다: +커스텀 dock menu를 설정하려면 `app.dock.setMenu` API를 사용하면 됩니다. +OS X에서만 사용 가능합니다: ```javascript const electron = require('electron'); @@ -123,26 +139,30 @@ app.dock.setMenu(dockMenu); Windows에선 JumpList의 `Tasks` 카테고리에 원하는 작업을 설정할 수 있습니다. MSDN에선 해당 기능을 다음과 같이 설명하고 있습니다: -> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을 예측하여 정의합니다. -> 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시 context-free를 유지해야 합니다. -> 작업은 일반 사용자가 프로그램을 실행하거나 이메일 프로그램으로 이메일을 작성하거나 달력을 불러오고 -> 워드 프로세서로 새 문서를 작성, 특정 모드, 부속 명령으로 프로그램을 실행하는 등의 -> 통계적, 일반적으로 가장 많이 사용되는 작업인지를 고려해야 합니다. -> 어플리케이션 작업은 일반 유저가 필요로 하지 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다. -> 작업에 특별 이벤트 또는 업그레이드 등의 홍보성 작업을 추가하면 안됩니다. +> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을 +> 예측하여 정의합니다. 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시 +> context-free를 유지해야 합니다. 작업은 일반 사용자가 프로그램을 실행하거나 이메일 +> 프로그램으로 이메일을 작성하거나 달력을 불러오고, 워드 프로세서로 새 문서를 작성, +> 특정 모드, 부속 명령으로 프로그램을 실행하는 등의 통계적, 일반적으로 가장 많이 +> 사용되는 작업인지를 고려해야 합니다. 어플리케이션 작업은 일반 유저가 필요로 하지 +> 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다. +> 또한 작업에 특별 이벤트 또는 업그레이드 등의 홍보성 작업을 추가하면 안됩니다. > > 작업 리스트는 가능한 한 정적으로 유지되는 것을 적극 권장합니다. > 이것은 동일한 상태 또는 응용 프로그램의 상태에 관계없이 유지되어야 합니다. -> 작업 목록은 동적으로 변경할 수 있지만 몇몇 유저는 예상하지 못한 작업 목록 변경에 혼동할 수 있다는 점을 고려해야 합니다. +> 작업 목록은 동적으로 변경할 수 있지만 몇몇 유저는 예상하지 못한 작업 목록 변경에 +> 혼란을 일으킬 수 있다는 점을 고려해야 합니다. __Internet Explorer의 작업:__ ![IE](http://i.msdn.microsoft.com/dynimg/IC420539.png) -OS X의 dock menu(진짜 메뉴)와는 달리 Windows의 사용자 작업은 어플리케이션 바로 가기처럼 작동합니다. -유저가 작업을 클릭할 때 설정한 인자와 함께 새로운 어플리케이션이 실행됩니다. +OS X의 dock menu(진짜 메뉴)와는 달리 Windows의 사용자 작업은 어플리케이션 바로 +가기처럼 작동합니다. 유저가 작업을 클릭할 때 설정한 인자와 함께 새로운 어플리케이션이 +실행됩니다. -사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] 메서드를 통해 구현할 수 있습니다: +사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] 메서드를 통해 구현할 +수 있습니다: ```javascript app.setUserTasks([ @@ -157,34 +177,39 @@ app.setUserTasks([ ]); ``` -작업 리스트를 비우려면 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어 호출하면 됩니다: +작업 리스트를 비우려면 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어 +호출하면 됩니다: ```javascript app.setUserTasks([]); ``` -사용자 작업 리스트는 어플리케이션이 삭제되지 않는 한 종료되어도 태스크바에 보존됩니다. 이러한 이유로 반드시 프로그램 경로와 아이콘 경로를 지정해야 합니다. +사용자 작업 리스트는 어플리케이션이 삭제되지 않는 한 종료되어도 태스크바에 보존됩니다. +이러한 이유로 반드시 프로그램 경로와 아이콘 경로를 지정해야 합니다. -## 섬네일 툴바 +## 미리보기 툴바 -Windows에선 작업 표시줄의 어플리케이션 선택시 나오는 미리보기에 특정한 섬네일 툴바를 추가할 수 있습니다. -이 기능은 유저가 윈도우를 활성화 하지 않고 특정한 커맨드를 실행시킬 수 있도록 할 수 있습니다. +Windows에선 작업 표시줄의 어플리케이션 선택시 나오는 미리보기에 특정한 미리보기 툴바를 +추가할 수 있습니다. 이 기능은 유저가 윈도우를 활성화 하지 않고 특정한 커맨드를 실행시킬 +수 있도록 할 수 있습니다. MSDN의 설명에 의하면: -> 이 툴바는 표준 툴바의 공통 컨트롤과 비슷한 역할을 합니다. 버튼은 최대 7개 까지 만들 수 있습니다. -> 각 버튼의 구조엔 ID, 이미지, 툴팁, 상태등이 정의되어있습니다. 태스크바에 구조가 전달되면 어플리케이션이 -> 상태에 따라 버튼을 숨기거나, 활성화하거나, 비활성화 할 수 있습니다. +> 이 툴바는 표준 툴바의 공통 컨트롤과 비슷한 역할을 합니다. 버튼은 최대 7개 까지 +> 만들 수 있습니다. 각 버튼의 구조엔 ID, 이미지, 툴팁, 상태 등이 정의되어있습니다. +> 작업표시줄에 구조가 전달되면 어플리케이션이 상태에 따라 버튼을 숨기거나, 활성화하거나, +> 비활성화 할 수 있습니다. > -> 예를 들어, 윈도우 미디어 플레이어는(WMP) 기본적으로 -> 미디어 플레이어가 공통적으로 사용하는 재생, 일시정지, 음소거, 정지등의 컨트롤을 포함하고 있습니다. +> 예를 들어, 윈도우 미디어 플레이어는(WMP) 미디어 플레이어가 공통적으로 사용하는 +> 재생, 일시정지, 음소거, 정지등의 컨트롤을 포함하고 있습니다. -__Windows Media Player의 섬네일 툴바:__ +__Windows Media Player의 미리보기 툴바:__ ![player](https://i-msdn.sec.s-msft.com/dynimg/IC420540.png) -[BrowserWindow.setThumbarButtons][setthumbarbuttons] API를 통해 어플리케이션에 섬네일 툴바를 설정할 수 있습니다: +[BrowserWindow.setThumbarButtons][setthumbarbuttons] API를 통해 어플리케이션에 +미리보기 툴바를 설정할 수 있습니다: ```javascript const BrowserWindow = require('electron').BrowserWindow; @@ -209,7 +234,8 @@ win.setThumbarButtons([ ]); ``` -섬네일 툴바를 비우려면 간단히 `BrowserWindow.setThumbarButtons` API에 빈 배열을 전달하면 됩니다: +미리보기 툴바를 비우려면 간단히 `BrowserWindow.setThumbarButtons` API에 빈 배열을 +전달하면 됩니다: ```javascript win.setThumbarButtons([]); @@ -217,7 +243,8 @@ win.setThumbarButtons([]); ## Unity 런처 숏컷 기능 (Linux) -Unity 환경에선 `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding Shortcuts to a Launcher][unity-launcher] 가이드를 참고하세요. +Unity 환경에선 `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 +있습니다. [Adding Shortcuts to a Launcher][unity-launcher] 가이드를 참고하세요. __Audacious의 런처 숏컷:__ @@ -226,7 +253,8 @@ __Audacious의 런처 숏컷:__ ## Taskbar progress 기능 (Windows & Unity) Windows에선 태스크바의 어플리케이션 버튼에 progress bar를 추가할 수 있습니다. -이 기능은 사용자가 어플리케이션의 창을 열지 않고도 어플리케이션의 작업의 상태 정보를 시각적으로 보여줄 수 있도록 해줍니다. +이 기능은 사용자가 어플리케이션의 창을 열지 않고도 어플리케이션의 작업의 상태 정보를 +시각적으로 보여줄 수 있도록 해줍니다. 또한 Unity DE도 런처에 progress bar를 부착할 수 있습니다. @@ -238,7 +266,8 @@ __Unity 런처의 progress bar:__ ![Unity Launcher](https://cloud.githubusercontent.com/assets/639601/5081747/4a0a589e-6f0f-11e4-803f-91594716a546.png) -이 기능은 [BrowserWindow.setProgressBar][setprogressbar] API를 사용하여 구현할 수 있습니다: +이 기능은 [BrowserWindow.setProgressBar][setprogressbar] API를 사용하여 구현할 수 +있습니다: ```javascript var window = new BrowserWindow({...}); @@ -247,14 +276,17 @@ window.setProgressBar(0.5); ## 대표 파일 제시 (OS X) -OS X는 창에서 대표 파일을 설정할 수 있습니다. 타이틀바에서 파일 아이콘이 있고, 사용자가 Command-Click 또는 Control-Click 키를 누를 경우 파일 경로 팝업이 보여집니다. -또한 창의 상태도 지정할 수 있습니다. 쉽게 말해 로드된 문서의 수정여부를 타이틀바 파일 아이콘에 표시할 수 있습니다. +OS X는 창에서 대표 파일을 설정할 수 있습니다. 타이틀바에서 파일 아이콘이 있고, 사용자가 +Command-Click 또는 Control-Click 키를 누를 경우 파일 경로 팝업이 보여집니다. 또한 +창의 상태도 지정할 수 있습니다. 다시 말해 로드된 문서의 수정 여부를 제목의 파일 +아이콘에 표시할 수 있습니다. __대표 파일 팝업 메뉴:__ -대표 파일 관련 API는 [BrowserWindow.setRepresentedFilename][setrepresentedfilename] 과 [BrowserWindow.setDocumentEdited][setdocumentedited]를 사용할 수 있습니다: +대표 파일 관련 API는 [BrowserWindow.setRepresentedFilename][setrepresentedfilename] 과 +[BrowserWindow.setDocumentEdited][setdocumentedited]를 사용할 수 있습니다: ```javascript var window = new BrowserWindow({...}); diff --git a/docs-translations/ko-KR/tutorial/devtools-extension.md b/docs-translations/ko-KR/tutorial/devtools-extension.md index 05ec389..655c6ed 100644 --- a/docs-translations/ko-KR/tutorial/devtools-extension.md +++ b/docs-translations/ko-KR/tutorial/devtools-extension.md @@ -1,13 +1,17 @@ # 개발자 도구 확장 기능 -어플리케이션의 디버깅을 쉽게 하기 위해 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)을 +사용합니다. 먼저 소스코드를 다운로드 받습니다: @@ -16,8 +20,8 @@ $ cd /some-directory $ 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)를 +통해 확장 기능을 개발하는 방법을 알아볼 수 있습니다. 그리고 개발자 도구에서 다음 코드를 입력하면 확장 기능을 로드할 수 있습니다: @@ -26,7 +30,8 @@ const BrowserWindow = require('electron').remote.BrowserWindow; BrowserWindow.addDevToolsExtension('/some-directory/react-devtools/shells/chrome'); ``` -확장 기능을 언로드 하고 콘솔을 다시 열 때 해당 확장 기능이 로드되지 않도록 하려면 `BrowserWindow.removeDevToolsExtension` API를 사용하면 됩니다: +확장 기능을 언로드 하고 콘솔을 다시 열 때 해당 확장 기능이 로드되지 않도록 하려면 +`BrowserWindow.removeDevToolsExtension` API를 사용하면 됩니다: ```javascript BrowserWindow.removeDevToolsExtension('React Developer Tools'); @@ -34,20 +39,25 @@ 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 diff --git a/docs-translations/ko-KR/tutorial/mac-app-store-submission-guide.md b/docs-translations/ko-KR/tutorial/mac-app-store-submission-guide.md index 3006808..d0322aa 100644 --- a/docs-translations/ko-KR/tutorial/mac-app-store-submission-guide.md +++ b/docs-translations/ko-KR/tutorial/mac-app-store-submission-guide.md @@ -1,24 +1,26 @@ # 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) 파일을 준비합니다. @@ -77,18 +79,20 @@ codesign -fs "$APP_KEY" --entitlements parent.plist "$APP_PATH" 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를 사용할 수 있습니다. -참고로 업로드하기 전에 [레코드][create-record]를 만들었는지 확인해야 합니다. -그리고 [심사를 위해 앱을 제출][submit-for-review]할 수 있습니다. +어플리케이션 서명을 완료한 후 iTunes Connect에 업로드하기 위해 Application Loader를 +사용할 수 있습니다. 참고로 업로드하기 전에 [레코드][create-record]를 만들었는지 +확인해야 합니다. 그리고 [심사를 위해 앱을 제출][submit-for-review]할 수 있습니다. ## MAS 빌드의 한계 -모든 어플리케이션 샌드박스에 대한 요구 사항을 충족시키기 위해, 다음 모듈들은 MAS 빌드에서 비활성화됩니다: +모든 어플리케이션 샌드박스에 대한 요구 사항을 충족시키기 위해, 다음 모듈들은 MAS +빌드에서 비활성화됩니다: * `crash-reporter` * `auto-updater` @@ -99,8 +103,9 @@ productbuild --component "$APP_PATH" /Applications --sign "$INSTALLER_KEY" "$RES * 특정 접근성 기능이 작동하지 않을 수 있습니다. * 어플리케이션이 DNS의 변경을 감지하지 못할 수 있습니다. -또한 어플리케이션 샌드박스 개념으로 인해 어플리케이션에서 접근할 수 있는 리소스는 엄격하게 제한되어 있습니다. -자세한 내용은 [App Sandboxing][app-sandboxing] 문서를 참고하세요. +또한 어플리케이션 샌드박스 개념으로 인해 어플리케이션에서 접근할 수 있는 리소스는 +엄격하게 제한되어 있습니다. 자세한 내용은 [App Sandboxing][app-sandboxing] 문서를 +참고하세요. **역주:** [Mac 앱 배포 가이드 공식 문서](https://developer.apple.com/osx/distribution/kr/) diff --git a/docs-translations/ko-KR/tutorial/online-offline-events.md b/docs-translations/ko-KR/tutorial/online-offline-events.md index 0b98951..f66e2e2 100644 --- a/docs-translations/ko-KR/tutorial/online-offline-events.md +++ b/docs-translations/ko-KR/tutorial/online-offline-events.md @@ -1,6 +1,7 @@ # 온라인/오프라인 이벤트 감지 -온라인/오프라인 이벤트는 다음 예제와 같이 랜더러 프로세스에서 표준 HTML5 API를 이용하여 구현할 수 있습니다. +온라인/오프라인 이벤트는 다음 예제와 같이 랜더러 프로세스에서 표준 HTML5 API를 이용하여 +구현할 수 있습니다. _main.js_ @@ -36,10 +37,12 @@ _online-status.html_ ``` -메인 프로세스에서 이 이벤트를 처리할 필요가 있는 경우 이벤트를 메인 프로세스로 보낼 수 있습니다. -메인 프로세스는 `navigator` 객체를 가지고 있지 않기 때문에 이 이벤트를 직접 사용할 수 없습니다. +메인 프로세스에서 이 이벤트를 처리할 필요가 있는 경우 이벤트를 메인 프로세스로 보낼 수 +있습니다. 메인 프로세스는 `navigator` 객체를 가지고 있지 않기 때문에 이 이벤트를 직접 +사용할 수는 없습니다. -대신 다음 예제와 같이 Electron의 inter-process communication(ipc) 유틸리티를 사용하면 이벤트를 메인 프로세스로 전달할 수 있습니다. +대신 다음 예제와 같이 Electron의 inter-process communication(ipc) 유틸리티를 +사용하면 이벤트를 메인 프로세스로 전달할 수 있습니다. _main.js_ diff --git a/docs-translations/ko-KR/tutorial/quick-start.md b/docs-translations/ko-KR/tutorial/quick-start.md index dea6a34..8946f44 100644 --- a/docs-translations/ko-KR/tutorial/quick-start.md +++ b/docs-translations/ko-KR/tutorial/quick-start.md @@ -2,38 +2,46 @@ ## 소개 -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 앱 만들기 @@ -47,9 +55,9 @@ your-app/ └── index.html ``` -`package.json`은 node 모듈의 package.json과 같습니다. -그리고 `main` 필드에 스크립트 파일을 지정하면 메인 프로세스의 엔트리 포인트로 사용합니다. -예를 들어 사용할 수 있는 `package.json`은 다음과 같습니다: +`package.json`은 node 모듈의 package.json과 같습니다. 그리고 `main` 필드에 스크립트 +파일을 지정하면 메인 프로세스의 엔트리 포인트로 사용합니다. 예를 들어 사용할 수 있는 +`package.json`은 다음과 같습니다: ```json { @@ -59,9 +67,11 @@ your-app/ } ``` -__알림__: 만약 `main` 필드가 `package.json`에 설정되어 있지 않으면 Electron은 자동으로 같은 디렉터리의 `index.js`를 로드합니다. +__알림__: 만약 `main` 필드가 `package.json`에 설정되어 있지 않으면 Electron은 +자동으로 같은 디렉터리의 `index.js`를 로드합니다. -반드시 `main.js`에서 창을 만들고 시스템 이밴트를 처리해야합니다. 대표적인 예제로 다음과 같이 작성할 수 있습니다: +반드시 `main.js`에서 창을 만들고 시스템 이밴트를 처리해야합니다. 대표적인 예제로 +다음과 같이 작성할 수 있습니다: ```javascript const electron = require('electron'); @@ -126,12 +136,14 @@ app.on('ready', function() { ## 앱 실행하기 -앱을 작성한 후 [어플리케이션 배포](application-distribution.md) 가이드를 따라 앱을 패키징 하고 패키징한 앱을 실행할 수 있습니다. -또한 Electron 실행파일을 다운로드 받아 바로 실행해 볼 수도 있습니다. +앱을 작성한 후 [어플리케이션 배포](application-distribution.md) 가이드를 따라 앱을 +패키징 하고 패키징한 앱을 실행할 수 있습니다. 또한 Electron 실행파일을 다운로드 받아 +바로 실행해 볼 수도 있습니다. ### electron-prebuilt 사용 -`npm`을 통해 `electron-prebuilt` 패키지를 전역에 설치하면 간단한 명령으로 앱을 실행할 수 있습니다. +`npm`을 통해 `electron-prebuilt` 패키지를 전역에 설치하면 간단한 명령으로 앱을 +실행할 수 있습니다. 앱 디렉터리 내에서 다음 명령으로 실행할 수 있습니다: @@ -178,13 +190,17 @@ $ ./Electron.app/Contents/MacOS/Electron your-app/ ### 배포용 실행 파일 만들기 -어플리케이션 작성을 모두 끝냈다면 [어플리케이션 배포](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를 설치하면 자동으로 같이 설치됩니다. @@ -195,4 +211,4 @@ $ git clone https://github.com/atom/electron-quick-start $ cd electron-quick-start # 어플리케이션의 종속성 모듈을 설치한 후 실행합니다 $ npm install && npm start -``` \ No newline at end of file +``` diff --git a/docs-translations/ko-KR/tutorial/supported-platforms.md b/docs-translations/ko-KR/tutorial/supported-platforms.md index 7a35da0..3b3a00d 100644 --- a/docs-translations/ko-KR/tutorial/supported-platforms.md +++ b/docs-translations/ko-KR/tutorial/supported-platforms.md @@ -8,18 +8,22 @@ OS X는 64비트 바이너리만 제공됩니다. 그리고 최소 OS X 지원 ### 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 diff --git a/docs-translations/ko-KR/tutorial/using-native-node-modules.md b/docs-translations/ko-KR/tutorial/using-native-node-modules.md index 45c4811..d1c3aa1 100644 --- a/docs-translations/ko-KR/tutorial/using-native-node-modules.md +++ b/docs-translations/ko-KR/tutorial/using-native-node-modules.md @@ -1,17 +1,22 @@ # 네이티브 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도 이 모듈을 통해 포팅된 네이티브 모듈을 사용할 수 있습니다. ## 네이티브 모듈을 설치하는 방법 @@ -20,9 +25,11 @@ 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 @@ -49,12 +56,14 @@ HOME=~/.electron-gyp npm install module-name ### `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`에게 알려줍니다. diff --git a/docs-translations/ko-KR/tutorial/using-pepper-flash-plugin.md b/docs-translations/ko-KR/tutorial/using-pepper-flash-plugin.md index cdb6f85..2f15a35 100644 --- a/docs-translations/ko-KR/tutorial/using-pepper-flash-plugin.md +++ b/docs-translations/ko-KR/tutorial/using-pepper-flash-plugin.md @@ -5,12 +5,14 @@ Pepper 플래시 플러그인을 사용하려면 Pepper 플래시 플러그인 ## 플래시 플러그인 준비하기 -크롬 브라우저의 `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 diff --git a/docs-translations/ko-KR/tutorial/using-selenium-and-webdriver.md b/docs-translations/ko-KR/tutorial/using-selenium-and-webdriver.md index ae58834..aba1625 100644 --- a/docs-translations/ko-KR/tutorial/using-selenium-and-webdriver.md +++ b/docs-translations/ko-KR/tutorial/using-selenium-and-webdriver.md @@ -3,17 +3,17 @@ [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. 크롬 드라이버 시작 @@ -35,8 +35,9 @@ $ npm install selenium-webdriver ### 3. 크롬 드라이버에 연결 -`selenium-webdriver`를 Electron과 같이 사용하는 방법은 기본적으로 upstream과 같습니다. -한가지 다른점이 있다면 수동으로 크롬 드라이버 연결에 대해 설정하고 Electron 실행파일의 위치를 전달합니다: +`selenium-webdriver`를 Electron과 같이 사용하는 방법은 기본적으로 upstream과 +같습니다. 한가지 다른점이 있다면 수동으로 크롬 드라이버 연결에 대해 설정하고 Electron +실행파일의 위치를 전달합니다: ```javascript const webdriver = require('selenium-webdriver'); @@ -67,7 +68,8 @@ driver.quit(); ## WebdriverIO 설정하기 -[WebdriverIO](http://webdriver.io/)는 웹 드라이버와 함께 테스트를 위해 제공되는 node 패키지입니다. +[WebdriverIO](http://webdriver.io/)는 웹 드라이버와 함께 테스트를 위해 제공되는 +node 패키지입니다. ### 1. 크롬 드라이버 시작 @@ -103,7 +105,7 @@ var options = { }; var client = webdriverio.remote(options); - + client .init() .url('http://google.com') @@ -117,10 +119,11 @@ client ## 작업 환경 -따로 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/ -- 2.7.4