Cleanup docs, fix typos
This commit is contained in:
Plusb Preco
parent
0232b77ce3
commit
eca98b85fc
22 changed files with 463 additions and 340 deletions
20
README-ko.md
20
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) 프로젝트에
|
||||
커뮤니티가 운영중인 유용한 예제 어플리케이션과 도구, 리소스가 있으니
|
||||
한번 참고해 보시기 바랍니다.
|
||||
커뮤니티가 운영중인 유용한 예제 어플리케이션과 도구, 리소스가 있으니 한번 참고해 보시기
|
||||
바랍니다.
|
||||
|
|
|
|||
|
|
@ -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. 다중 컨텍스트__
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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비트는 지원할
|
||||
계획이 없습니다.
|
||||
|
||||
## 테스트
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 하기 위해
|
||||
빌드 하는 것이라면 이 문제에 신경 쓸 필요가 없습니다.
|
||||
|
|
|
|||
|
|
@ -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)가
|
||||
진행되고 있습니다.
|
||||
|
|
|
|||
|
|
@ -1,29 +1,36 @@
|
|||
# 디버거에서 디버그 심볼 서버 설정
|
||||
|
||||
디버그 심볼은 디버깅 세션을 더 좋게 개선해 줍니다. 디버그 심볼은 실행 파일과 동적 링크 라이브러리에서 메서드에 대한 정보를 담고 있으며 명료한 함수 호출 스텍 정보를 제공합니다.
|
||||
심볼 서버는 유저가 크기가 큰 디버깅용 파일을 필수적으로 다운로드 받지 않고도 디버거가 알맞은 심볼, 바이너리 그리고 소스를 자동적으로 로드할 수 있도록 해줍니다.
|
||||
서버 사용법은 [Microsoft의 심볼 서버](http://support.microsoft.com/kb/311503)와 비슷합니다. 이 문서를 참조하세요.
|
||||
디버그 심볼은 디버깅 세션을 더 좋게 개선해 줍니다. 디버그 심볼은 실행 파일과 동적 링크
|
||||
라이브러리에서 메서드에 대한 정보를 담고 있으며 명료한 함수 호출 스텍 정보를 제공합니다.
|
||||
심볼 서버는 유저가 크기가 큰 디버깅용 파일을 필수적으로 다운로드 받지 않고도 디버거가
|
||||
알맞은 심볼, 바이너리 그리고 소스를 자동적으로 로드할 수 있도록 해줍니다. 서버 사용법은
|
||||
[Microsoft의 심볼 서버](http://support.microsoft.com/kb/311503)와 비슷합니다.
|
||||
사용법을 알아보려면 이 문서를 참조하세요.
|
||||
|
||||
참고로 릴리즈된 Electron 빌드는 자체적으로 많은 최적화가 되어 있는 관계로 경우에 따라 디버깅이 쉽지 않을 수 있습니다.
|
||||
Inlining, tail call 등의 컴파일러 최적화에 의해 디버거가 모든 변수의 컨텐츠를 보여줄 수 없는 경우도 있고 실행 경로가 이상하게 보여질 수 있습니다.
|
||||
유일한 해결 방법은 최적화되지 않은 로컬 빌드를 하는 것입니다.
|
||||
참고로 릴리즈된 Electron 빌드는 자체적으로 많은 최적화가 되어 있는 관계로 경우에 따라
|
||||
디버깅이 쉽지 않을 수 있습니다. Inlining, tail call 등 컴파일러 최적화에 의해 디버거가
|
||||
모든 변수의 컨텐츠를 보여줄 수 없는 경우도 있고 실행 경로가 이상하게 보여지는 경우도
|
||||
있습니다. 유일한 해결 방법은 최적화되지 않은 로컬 빌드를 하는 것입니다.
|
||||
|
||||
공식적인 Electron의 심볼 서버의 URL은 http://54.249.141.255:8086/atom-shell/symbols 입니다.
|
||||
일단 이 URL에 직접적으로 접근할 수는 없습니다: 디버깅 툴에 심볼의 경로를 추가해야합니다.
|
||||
아래의 예제를 참고하면 로컬 캐시 디렉터리는 서버로부터 중복되지 않게 PDB를 가져오는데 사용됩니다.
|
||||
공식적인 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
|
||||
|
|
|
|||
|
|
@ -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` 빌드를 지원하지 않아 따로 다운로드된 서드파티
|
||||
프레임워크 바이너리들.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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,12 +102,13 @@ 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)
|
||||
|
|
@ -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 모듈 또한 새로운 실행파일 이름으로 일치시킵니다.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:__
|
|||
|
||||
<img src="https://cloud.githubusercontent.com/assets/639601/5069610/2aa80758-6e97-11e4-8cfb-c1a414a10774.png" height="353" width="428" >
|
||||
|
||||
파일을 최근 문서에 추가하려면 [app.addRecentDocument][addrecentdocument] API를 사용할 수 있습니다:
|
||||
파일을 최근 문서에 추가하려면 [app.addRecentDocument][addrecentdocument] API를
|
||||
사용할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
app.addRecentDocument('/Users/USERNAME/Desktop/work.type');
|
||||
```
|
||||
|
||||
그리고 [app.clearRecentDocuments][clearrecentdocuments] API로 최근 문서 리스트를 비울 수 있습니다:
|
||||
그리고 [app.clearRecentDocuments][clearrecentdocuments] API로 최근 문서 리스트를
|
||||
비울 수 있습니다:
|
||||
|
||||
```javascript
|
||||
app.clearRecentDocuments();
|
||||
|
|
@ -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:__
|
|||
|
||||
<img src="https://cloud.githubusercontent.com/assets/639601/5069962/6032658a-6e9c-11e4-9953-aa84006bdfff.png" height="354" width="341" >
|
||||
|
||||
커스텀 dock menu를 설정하려면 `app.dock.setMenu` API를 사용하면 됩니다. OS X에서만 사용 가능합니다:
|
||||
커스텀 dock menu를 설정하려면 `app.dock.setMenu` API를 사용하면 됩니다.
|
||||
OS X에서만 사용 가능합니다:
|
||||
|
||||
```javascript
|
||||
const electron = require('electron');
|
||||
|
|
@ -123,26 +139,30 @@ app.dock.setMenu(dockMenu);
|
|||
Windows에선 JumpList의 `Tasks` 카테고리에 원하는 작업을 설정할 수 있습니다.
|
||||
MSDN에선 해당 기능을 다음과 같이 설명하고 있습니다:
|
||||
|
||||
> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을 예측하여 정의합니다.
|
||||
> 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시 context-free를 유지해야 합니다.
|
||||
> 작업은 일반 사용자가 프로그램을 실행하거나 이메일 프로그램으로 이메일을 작성하거나 달력을 불러오고
|
||||
> 워드 프로세서로 새 문서를 작성, 특정 모드, 부속 명령으로 프로그램을 실행하는 등의
|
||||
> 통계적, 일반적으로 가장 많이 사용되는 작업인지를 고려해야 합니다.
|
||||
> 어플리케이션 작업은 일반 유저가 필요로 하지 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다.
|
||||
> 작업에 특별 이벤트 또는 업그레이드 등의 홍보성 작업을 추가하면 안됩니다.
|
||||
> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을
|
||||
> 예측하여 정의합니다. 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시
|
||||
> context-free를 유지해야 합니다. 작업은 일반 사용자가 프로그램을 실행하거나 이메일
|
||||
> 프로그램으로 이메일을 작성하거나 달력을 불러오고, 워드 프로세서로 새 문서를 작성,
|
||||
> 특정 모드, 부속 명령으로 프로그램을 실행하는 등의 통계적, 일반적으로 가장 많이
|
||||
> 사용되는 작업인지를 고려해야 합니다. 어플리케이션 작업은 일반 유저가 필요로 하지
|
||||
> 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다.
|
||||
> 또한 작업에 특별 이벤트 또는 업그레이드 등의 홍보성 작업을 추가하면 안됩니다.
|
||||
>
|
||||
> 작업 리스트는 가능한 한 정적으로 유지되는 것을 적극 권장합니다.
|
||||
> 이것은 동일한 상태 또는 응용 프로그램의 상태에 관계없이 유지되어야 합니다.
|
||||
> 작업 목록은 동적으로 변경할 수 있지만 몇몇 유저는 예상하지 못한 작업 목록 변경에 혼동할 수 있다는 점을 고려해야 합니다.
|
||||
> 작업 목록은 동적으로 변경할 수 있지만 몇몇 유저는 예상하지 못한 작업 목록 변경에
|
||||
> 혼란을 일으킬 수 있다는 점을 고려해야 합니다.
|
||||
|
||||
__Internet Explorer의 작업:__
|
||||
|
||||
|
||||
|
||||
OS X의 dock menu(진짜 메뉴)와는 달리 Windows의 사용자 작업은 어플리케이션 바로 가기처럼 작동합니다.
|
||||
유저가 작업을 클릭할 때 설정한 인자와 함께 새로운 어플리케이션이 실행됩니다.
|
||||
OS X의 dock menu(진짜 메뉴)와는 달리 Windows의 사용자 작업은 어플리케이션 바로
|
||||
가기처럼 작동합니다. 유저가 작업을 클릭할 때 설정한 인자와 함께 새로운 어플리케이션이
|
||||
실행됩니다.
|
||||
|
||||
사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] 메서드를 통해 구현할 수 있습니다:
|
||||
사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] 메서드를 통해 구현할
|
||||
수 있습니다:
|
||||
|
||||
```javascript
|
||||
app.setUserTasks([
|
||||
|
|
@ -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의 미리보기 툴바:__
|
||||
|
||||
|
||||
|
||||
[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:__
|
|||
|
||||
|
||||
|
||||
이 기능은 [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 키를 누를 경우 파일 경로 팝업이 보여집니다. 또한
|
||||
창의 상태도 지정할 수 있습니다. 다시 말해 로드된 문서의 수정 여부를 제목의 파일
|
||||
아이콘에 표시할 수 있습니다.
|
||||
|
||||
__대표 파일 팝업 메뉴:__
|
||||
|
||||
<img src="https://cloud.githubusercontent.com/assets/639601/5082061/670a949a-6f14-11e4-987a-9aaa04b23c1d.png" height="232" width="663" >
|
||||
|
||||
대표 파일 관련 API는 [BrowserWindow.setRepresentedFilename][setrepresentedfilename] 과 [BrowserWindow.setDocumentEdited][setdocumentedited]를 사용할 수 있습니다:
|
||||
대표 파일 관련 API는 [BrowserWindow.setRepresentedFilename][setrepresentedfilename] 과
|
||||
[BrowserWindow.setDocumentEdited][setdocumentedited]를 사용할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var window = new BrowserWindow({...});
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
# 온라인/오프라인 이벤트 감지
|
||||
|
||||
온라인/오프라인 이벤트는 다음 예제와 같이 랜더러 프로세스에서 표준 HTML5 API를 이용하여 구현할 수 있습니다.
|
||||
온라인/오프라인 이벤트는 다음 예제와 같이 랜더러 프로세스에서 표준 HTML5 API를 이용하여
|
||||
구현할 수 있습니다.
|
||||
|
||||
_main.js_
|
||||
|
||||
|
|
@ -36,10 +37,12 @@ _online-status.html_
|
|||
</html>
|
||||
```
|
||||
|
||||
메인 프로세스에서 이 이벤트를 처리할 필요가 있는 경우 이벤트를 메인 프로세스로 보낼 수 있습니다.
|
||||
메인 프로세스는 `navigator` 객체를 가지고 있지 않기 때문에 이 이벤트를 직접 사용할 수 없습니다.
|
||||
메인 프로세스에서 이 이벤트를 처리할 필요가 있는 경우 이벤트를 메인 프로세스로 보낼 수
|
||||
있습니다. 메인 프로세스는 `navigator` 객체를 가지고 있지 않기 때문에 이 이벤트를 직접
|
||||
사용할 수는 없습니다.
|
||||
|
||||
대신 다음 예제와 같이 Electron의 inter-process communication(ipc) 유틸리티를 사용하면 이벤트를 메인 프로세스로 전달할 수 있습니다.
|
||||
대신 다음 예제와 같이 Electron의 inter-process communication(ipc) 유틸리티를
|
||||
사용하면 이벤트를 메인 프로세스로 전달할 수 있습니다.
|
||||
|
||||
_main.js_
|
||||
|
||||
|
|
|
|||
|
|
@ -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를 설치하면 자동으로 같이 설치됩니다.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)의 예제를 참고하세요)
|
||||
사용하는 네이티브 모듈이 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에 맞게 포팅할 수 있습니다.
|
||||
혹시 직접 만든 네이티브 모듈이 있다면 [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`에게 알려줍니다.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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. 크롬 드라이버 시작
|
||||
|
||||
|
|
@ -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/
|
||||
|
|
|
|||
Loading…
Reference in a new issue