Merge pull request #2093 from preco21/master
Translate docs into korean #2 + added link of power-save-blocker API to README
This commit is contained in:
Cheng Zhao
commit
4e94e0c82f
50 changed files with 4034 additions and 218 deletions
|
|
@ -33,8 +33,8 @@ npm install electron-prebuilt --save-dev
|
|||
|
||||
## 참조문서
|
||||
|
||||
[docs](https://github.com/preco21/electron/tree/master/docs) 에 프레임워크 사용 가이드와 API 레퍼런스가 있습니다.
|
||||
또한, Electron을 빌드 하는 방법과 프로젝트에 기여하는 방법 문서에 포함되어 있으니 참고바랍니다.
|
||||
[docs](https://github.com/atom/electron/tree/master/docs/README-ko.md) 에 프레임워크 사용 가이드와 API 레퍼런스가 있습니다.
|
||||
추가적으로 Electron을 빌드 하는 방법과 프로젝트에 기여하는 방법도 문서에 포함되어 있으니 참고하기 바랍니다.
|
||||
|
||||
## 커뮤니티
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
|
||||
* [개요](api/synopsis-ko.md)
|
||||
* [프로세스 객체](api/process-ko.md)
|
||||
* [크롬 Command-Line 스위치에 대한 지원](api/chrome-command-line-switches-ko.md)
|
||||
* [크롬 Command-Line 스위치 지원](api/chrome-command-line-switches-ko.md)
|
||||
|
||||
커스텀 DOM Element:
|
||||
|
||||
|
|
@ -38,6 +38,7 @@
|
|||
* [menu](api/menu-ko.md)
|
||||
* [menu-item](api/menu-item-ko.md)
|
||||
* [power-monitor](api/power-monitor-ko.md)
|
||||
* [power-save-blocker](api/power-save-blocker-ko.md)
|
||||
* [protocol](api/protocol-ko.md)
|
||||
* [tray](api/tray-ko.md)
|
||||
|
||||
|
|
@ -58,7 +59,7 @@
|
|||
## 개발자용
|
||||
|
||||
* [코딩 스타일](development/coding-style-ko.md)
|
||||
* [소스코드 구조](development/source-code-directory-structure-ko.md)
|
||||
* [소스 코드 디렉터리 구조](development/source-code-directory-structure-ko.md)
|
||||
* [NW.js와 기술적으로 다른점 (이전 node-webkit)](development/atom-shell-vs-node-webkit-ko.md)
|
||||
* [빌드 시스템 개요](development/build-system-overview-ko.md)
|
||||
* [빌드 설명서 (Mac)](development/build-instructions-mac-ko.md)
|
||||
|
|
@ -66,4 +67,5 @@
|
|||
* [빌드 설명서 (Linux)](development/build-instructions-linux-ko.md)
|
||||
* [디버거에서 디버그 심볼 서버 설정](development/setting-up-symbol-server-ko.md)
|
||||
|
||||
이 문서는 (@preco21)[https://github.com/preco21]이 번역하였습니다.
|
||||
이 문서는 [@preco21](https://github.com/preco21) 에 의해 번역되었습니다.
|
||||
문서내에서 오타나 잘못된 번역이 발견될 경우 해당 repo를 fork한 후 수정하여 PR을 올리거나 `plusb21@gmail.com` 이메일로 알려주시면 감사하겠습니다.
|
||||
|
|
|
|||
|
|
@ -38,6 +38,7 @@ Modules for the main process:
|
|||
* [menu](api/menu.md)
|
||||
* [menu-item](api/menu-item.md)
|
||||
* [power-monitor](api/power-monitor.md)
|
||||
* [power-save-blocker](api/power-save-blocker.md)
|
||||
* [protocol](api/protocol.md)
|
||||
* [tray](api/tray.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Accelerator
|
||||
# Accelerator
|
||||
|
||||
Accelerator는 키보드 단축키를 표현하는 문자열입니다, 여러 혼합키와 키코드를 `+` 문자를
|
||||
이용하여 결합할 수 있습니다.
|
||||
|
|
|
|||
317
docs/api/app-ko.md
Normal file
317
docs/api/app-ko.md
Normal file
|
|
@ -0,0 +1,317 @@
|
|||
# app
|
||||
|
||||
The `app` module is responsible for controlling the application's life time.
|
||||
|
||||
The example of quitting the whole application when the last window is closed:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
app.on('window-all-closed', function() {
|
||||
app.quit();
|
||||
});
|
||||
```
|
||||
|
||||
## Event: will-finish-launching
|
||||
|
||||
Emitted when application has done basic startup. On Windows and Linux it is the
|
||||
same with `ready` event, on OS X this event represents the
|
||||
`applicationWillFinishLaunching` message of `NSApplication`, usually you would
|
||||
setup listeners to `open-file` and `open-url` events here, and start the crash
|
||||
reporter and auto updater.
|
||||
|
||||
Under most cases you should just do everything in `ready` event.
|
||||
|
||||
## Event: ready
|
||||
|
||||
Emitted when Electron has done everything initialization.
|
||||
|
||||
## Event: window-all-closed
|
||||
|
||||
Emitted when all windows have been closed.
|
||||
|
||||
This event is only emitted when the application is not going to quit. If a
|
||||
user pressed `Cmd + Q`, or the developer called `app.quit()`, Electron would
|
||||
first try to close all windows and then emit the `will-quit` event, and in
|
||||
this case the `window-all-closed` would not be emitted.
|
||||
|
||||
## Event: before-quit
|
||||
|
||||
* `event` Event
|
||||
|
||||
Emitted before the application starts closing its windows.
|
||||
Calling `event.preventDefault()` will prevent the default behaviour, which is
|
||||
terminating the application.
|
||||
|
||||
## Event: will-quit
|
||||
|
||||
* `event` Event
|
||||
|
||||
Emitted when all windows have been closed and the application will quit.
|
||||
Calling `event.preventDefault()` will prevent the default behaviour, which is
|
||||
terminating the application.
|
||||
|
||||
See description of `window-all-closed` for the differences between `will-quit`
|
||||
and it.
|
||||
|
||||
## Event: quit
|
||||
|
||||
Emitted when application is quitting.
|
||||
|
||||
## Event: open-file
|
||||
|
||||
* `event` Event
|
||||
* `path` String
|
||||
|
||||
Emitted when user wants to open a file with the application, it usually happens
|
||||
when the application is already opened and then OS wants to reuse the
|
||||
application to open file. But it is also emitted when a file is dropped onto the
|
||||
dock and the application is not yet running. Make sure to listen to open-file
|
||||
very early in your application startup to handle this case (even before the
|
||||
`ready` event is emitted).
|
||||
|
||||
You should call `event.preventDefault()` if you want to handle this event.
|
||||
|
||||
## Event: open-url
|
||||
|
||||
* `event` Event
|
||||
* `url` String
|
||||
|
||||
Emitted when user wants to open a URL with the application, this URL scheme
|
||||
must be registered to be opened by your application.
|
||||
|
||||
You should call `event.preventDefault()` if you want to handle this event.
|
||||
|
||||
## Event: activate-with-no-open-windows
|
||||
|
||||
Emitted when the application is activated while there is no opened windows. It
|
||||
usually happens when user has closed all of application's windows and then
|
||||
click on the application's dock icon.
|
||||
|
||||
## Event: browser-window-blur
|
||||
|
||||
* `event` Event
|
||||
* `window` BrowserWindow
|
||||
|
||||
Emitted when a [browserWindow](browser-window-ko.md) gets blurred.
|
||||
|
||||
## Event: browser-window-focus
|
||||
|
||||
* `event` Event
|
||||
* `window` BrowserWindow
|
||||
|
||||
Emitted when a [browserWindow](browser-window-ko.md) gets focused.
|
||||
|
||||
### Event: 'select-certificate'
|
||||
|
||||
Emitted when client certificate is requested.
|
||||
|
||||
* `event` Event
|
||||
* `webContents` [WebContents](browser-window-ko.md#class-webcontents)
|
||||
* `url` String
|
||||
* `certificateList` [Objects]
|
||||
* `data` PEM encoded data
|
||||
* `issuerName` Issuer's Common Name
|
||||
* `callback` Function
|
||||
|
||||
```
|
||||
app.on('select-certificate', function(event, host, url, list, callback) {
|
||||
event.preventDefault();
|
||||
callback(list[0]);
|
||||
})
|
||||
```
|
||||
|
||||
`url` corresponds to the navigation entry requesting the client certificate,
|
||||
`callback` needs to be called with an entry filtered from the list.
|
||||
`event.preventDefault()` prevents from using the first certificate from
|
||||
the store.
|
||||
|
||||
### Event: 'gpu-process-crashed'
|
||||
|
||||
Emitted when the gpu process is crashed.
|
||||
|
||||
## app.quit()
|
||||
|
||||
Try to close all windows. The `before-quit` event will first be emitted. If all
|
||||
windows are successfully closed, the `will-quit` event will be emitted and by
|
||||
default the application would be terminated.
|
||||
|
||||
This method guarantees all `beforeunload` and `unload` handlers are correctly
|
||||
executed. It is possible that a window cancels the quitting by returning
|
||||
`false` in `beforeunload` handler.
|
||||
|
||||
## app.getPath(name)
|
||||
|
||||
* `name` String
|
||||
|
||||
Retrieves a path to a special directory or file associated with `name`. On
|
||||
failure an `Error` would throw.
|
||||
|
||||
You can request following paths by the names:
|
||||
|
||||
* `home`: User's home directory
|
||||
* `appData`: Per-user application data directory, by default it is pointed to:
|
||||
* `%APPDATA%` on Windows
|
||||
* `$XDG_CONFIG_HOME` or `~/.config` on Linux
|
||||
* `~/Library/Application Support` on OS X
|
||||
* `userData`: The directory for storing your app's configuration files, by
|
||||
default it is the `appData` directory appended with your app's name
|
||||
* `cache`: Per-user application cache directory, by default it is pointed to:
|
||||
* `%APPDATA%` on Window, which doesn't has a universal place for cache
|
||||
* `$XDG_CACHE_HOME` or `~/.cache` on Linux
|
||||
* `~/Library/Caches` on OS X
|
||||
* `userCache`: The directory for placing your app's caches, by default it is the
|
||||
`cache` directory appended with your app's name
|
||||
* `temp`: Temporary directory
|
||||
* `userDesktop`: The current user's Desktop directory
|
||||
* `exe`: The current executable file
|
||||
* `module`: The `libchromiumcontent` library
|
||||
|
||||
## app.setPath(name, path)
|
||||
|
||||
* `name` String
|
||||
* `path` String
|
||||
|
||||
Overrides the `path` to a special directory or file associated with `name`. if
|
||||
the path specifies a directory that does not exist, the directory will be
|
||||
created by this method. On failure an `Error` would throw.
|
||||
|
||||
You can only override paths of `name`s defined in `app.getPath`.
|
||||
|
||||
By default web pages' cookies and caches will be stored under `userData`
|
||||
directory, if you want to change this location, you have to override the
|
||||
`userData` path before the `ready` event of `app` module gets emitted.
|
||||
|
||||
## app.getVersion()
|
||||
|
||||
Returns the version of loaded application, if no version is found in
|
||||
application's `package.json`, the version of current bundle or executable would
|
||||
be returned.
|
||||
|
||||
## app.getName()
|
||||
|
||||
Returns current application's name, the name in `package.json` would be
|
||||
used.
|
||||
|
||||
Usually the `name` field of `package.json` is a short lowercased name, according
|
||||
to the spec of npm modules. So usually you should also specify a `productName`
|
||||
field, which is your application's full capitalized name, and it will be
|
||||
preferred over `name` by Electron.
|
||||
|
||||
## app.resolveProxy(url, callback)
|
||||
|
||||
* `url` URL
|
||||
* `callback` Function
|
||||
|
||||
Resolves the proxy information for `url`, the `callback` would be called with
|
||||
`callback(proxy)` when the request is done.
|
||||
|
||||
## app.addRecentDocument(path)
|
||||
|
||||
* `path` String
|
||||
|
||||
Adds `path` to recent documents list.
|
||||
|
||||
This list is managed by the system, on Windows you can visit the list from task
|
||||
bar, and on Mac you can visit it from dock menu.
|
||||
|
||||
## app.clearRecentDocuments()
|
||||
|
||||
Clears the recent documents list.
|
||||
|
||||
## app.setUserTasks(tasks)
|
||||
|
||||
* `tasks` Array - Array of `Task` objects
|
||||
|
||||
Adds `tasks` to the [Tasks][tasks] category of JumpList on Windows.
|
||||
|
||||
The `tasks` is an array of `Task` objects in following format:
|
||||
|
||||
* `Task` Object
|
||||
* `program` String - Path of the program to execute, usually you should
|
||||
specify `process.execPath` which opens current program
|
||||
* `arguments` String - The arguments of command line when `program` is
|
||||
executed
|
||||
* `title` String - The string to be displayed in a JumpList
|
||||
* `description` String - Description of this task
|
||||
* `iconPath` String - The absolute path to an icon to be displayed in a
|
||||
JumpList, it can be arbitrary resource file that contains an icon, usually
|
||||
you can specify `process.execPath` to show the icon of the program
|
||||
* `iconIndex` Integer - The icon index in the icon file. If an icon file
|
||||
consists of two or more icons, set this value to identify the icon. If an
|
||||
icon file consists of one icon, this value is 0
|
||||
|
||||
**Note:** This API is only available on Windows.
|
||||
|
||||
## app.commandLine.appendSwitch(switch, [value])
|
||||
|
||||
Append a switch [with optional value] to Chromium's command line.
|
||||
|
||||
**Note:** This will not affect `process.argv`, and is mainly used by developers
|
||||
to control some low-level Chromium behaviors.
|
||||
|
||||
## app.commandLine.appendArgument(value)
|
||||
|
||||
Append an argument to Chromium's command line. The argument will quoted properly.
|
||||
|
||||
**Note:** This will not affect `process.argv`.
|
||||
|
||||
## app.dock.bounce([type])
|
||||
|
||||
* `type` String - Can be `critical` or `informational`, the default is
|
||||
`informational`
|
||||
|
||||
When `critical` is passed, the dock icon will bounce until either the
|
||||
application becomes active or the request is canceled.
|
||||
|
||||
When `informational` is passed, the dock icon will bounce for one second. The
|
||||
request, though, remains active until either the application becomes active or
|
||||
the request is canceled.
|
||||
|
||||
An ID representing the request would be returned.
|
||||
|
||||
**Note:** This API is only available on Mac.
|
||||
|
||||
## app.dock.cancelBounce(id)
|
||||
|
||||
* `id` Integer
|
||||
|
||||
Cancel the bounce of `id`.
|
||||
|
||||
**Note:** This API is only available on Mac.
|
||||
|
||||
## app.dock.setBadge(text)
|
||||
|
||||
* `text` String
|
||||
|
||||
Sets the string to be displayed in the dock’s badging area.
|
||||
|
||||
**Note:** This API is only available on Mac.
|
||||
|
||||
## app.dock.getBadge()
|
||||
|
||||
Returns the badge string of the dock.
|
||||
|
||||
**Note:** This API is only available on Mac.
|
||||
|
||||
## app.dock.hide()
|
||||
|
||||
Hides the dock icon.
|
||||
|
||||
**Note:** This API is only available on Mac.
|
||||
|
||||
## app.dock.show()
|
||||
|
||||
Shows the dock icon.
|
||||
|
||||
**Note:** This API is only available on Mac.
|
||||
|
||||
## app.dock.setMenu(menu)
|
||||
|
||||
* `menu` Menu
|
||||
|
||||
Sets the application [dock menu][dock-menu].
|
||||
|
||||
**Note:** This API is only available on Mac.
|
||||
|
||||
[dock-menu]:https://developer.apple.com/library/mac/documentation/Carbon/Conceptual/customizing_docktile/concepts/dockconcepts.html#//apple_ref/doc/uid/TP30000986-CH2-TPXREF103
|
||||
[tasks]:http://msdn.microsoft.com/en-us/library/windows/desktop/dd378460(v=vs.85).aspx#tasks
|
||||
143
docs/api/auto-updater-ko.md
Normal file
143
docs/api/auto-updater-ko.md
Normal file
|
|
@ -0,0 +1,143 @@
|
|||
# auto-updater
|
||||
|
||||
**This module has only been implemented for OS X.**
|
||||
|
||||
Check out [atom/grunt-electron-installer](https://github.com/atom/grunt-electron-installer)
|
||||
for building a Windows installer for your app.
|
||||
|
||||
The `auto-updater` module is a simple wrap around the
|
||||
[Squirrel.Mac](https://github.com/Squirrel/Squirrel.Mac) framework.
|
||||
|
||||
Squirrel.Mac requires that your `.app` folder is signed using the
|
||||
[codesign](https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/codesign.1.html)
|
||||
utility for updates to be installed.
|
||||
|
||||
## Squirrel
|
||||
|
||||
Squirrel is an OS X framework focused on making application updates **as safe
|
||||
and transparent as updates to a website**.
|
||||
|
||||
Instead of publishing a feed of versions from which your app must select,
|
||||
Squirrel updates to the version your server tells it to. This allows you to
|
||||
intelligently update your clients based on the request you give to Squirrel.
|
||||
|
||||
Your request can include authentication details, custom headers or a request
|
||||
body so that your server has the context it needs in order to supply the most
|
||||
suitable update.
|
||||
|
||||
The update JSON Squirrel requests should be dynamically generated based on
|
||||
criteria in the request, and whether an update is required. Squirrel relies
|
||||
on server side support for determining whether an update is required, see
|
||||
[Server Support](#server-support).
|
||||
|
||||
Squirrel's installer is also designed to be fault tolerant, and ensure that any
|
||||
updates installed are valid.
|
||||
|
||||
## Update Requests
|
||||
|
||||
Squirrel is indifferent to the request the client application provides for
|
||||
update checking. `Accept: application/json` is added to the request headers
|
||||
because Squirrel is responsible for parsing the response.
|
||||
|
||||
For the requirements imposed on the responses and the body format of an update
|
||||
response see [Server Support](#server-support).
|
||||
|
||||
Your update request must *at least* include a version identifier so that the
|
||||
server can determine whether an update for this specific version is required. It
|
||||
may also include other identifying criteria such as operating system version or
|
||||
username, to allow the server to deliver as fine grained an update as you
|
||||
would like.
|
||||
|
||||
How you include the version identifier or other criteria is specific to the
|
||||
server that you are requesting updates from. A common approach is to use query
|
||||
parameters, like this:
|
||||
|
||||
```javascript
|
||||
// On the main process
|
||||
var app = require('app');
|
||||
var autoUpdater = require('auto-updater');
|
||||
autoUpdater.setFeedUrl('http://mycompany.com/myapp/latest?version=' + app.getVersion());
|
||||
```
|
||||
|
||||
## Server Support
|
||||
|
||||
Your server should determine whether an update is required based on the
|
||||
[Update Request](#update-requests) your client issues.
|
||||
|
||||
If an update is required your server should respond with a status code of
|
||||
[200 OK](http://tools.ietf.org/html/rfc2616#section-10.2.1) and include the
|
||||
[update JSON](#update-json-format) in the body. Squirrel **will** download and
|
||||
install this update, even if the version of the update is the same as the
|
||||
currently running version. To save redundantly downloading the same version
|
||||
multiple times your server must not inform the client to update.
|
||||
|
||||
If no update is required your server must respond with a status code of
|
||||
[204 No Content](http://tools.ietf.org/html/rfc2616#section-10.2.5). Squirrel
|
||||
will check for an update again at the interval you specify.
|
||||
|
||||
## Update JSON Format
|
||||
|
||||
When an update is available, Squirrel expects the following schema in response
|
||||
to the update request provided:
|
||||
|
||||
```json
|
||||
{
|
||||
"url": "http://mycompany.com/myapp/releases/myrelease",
|
||||
"name": "My Release Name",
|
||||
"notes": "Theses are some release notes innit",
|
||||
"pub_date": "2013-09-18T12:29:53+01:00",
|
||||
}
|
||||
```
|
||||
|
||||
The only required key is "url", the others are optional.
|
||||
|
||||
Squirrel will request "url" with `Accept: application/zip` and only supports
|
||||
installing ZIP updates. If future update formats are supported their MIME type
|
||||
will be added to the `Accept` header so that your server can return the
|
||||
appropriate format.
|
||||
|
||||
`pub_date` if present must be formatted according to ISO 8601.
|
||||
|
||||
## Event: error
|
||||
|
||||
* `event` Event
|
||||
* `message` String
|
||||
|
||||
Emitted when there is an error updating.
|
||||
|
||||
## Event: checking-for-update
|
||||
|
||||
Emitted when checking for update has started.
|
||||
|
||||
## Event: update-available
|
||||
|
||||
Emitted when there is an available update, the update would be downloaded
|
||||
automatically.
|
||||
|
||||
## Event: update-not-available
|
||||
|
||||
Emitted when there is no available update.
|
||||
|
||||
## Event: update-downloaded
|
||||
|
||||
* `event` Event
|
||||
* `releaseNotes` String
|
||||
* `releaseName` String
|
||||
* `releaseDate` Date
|
||||
* `updateUrl` String
|
||||
* `quitAndUpdate` Function
|
||||
|
||||
Emitted when update has been downloaded, calling `quitAndUpdate()` would restart
|
||||
the application and install the update.
|
||||
|
||||
## autoUpdater.setFeedUrl(url)
|
||||
|
||||
* `url` String
|
||||
|
||||
Set the `url` and initialize the auto updater. The `url` could not be changed
|
||||
once it is set.
|
||||
|
||||
## autoUpdater.checkForUpdates()
|
||||
|
||||
Ask the server whether there is an update, you have to call `setFeedUrl` before
|
||||
using this API.
|
||||
1143
docs/api/browser-window-ko.md
Normal file
1143
docs/api/browser-window-ko.md
Normal file
File diff suppressed because it is too large
Load diff
109
docs/api/chrome-command-line-switches-ko.md
Normal file
109
docs/api/chrome-command-line-switches-ko.md
Normal file
|
|
@ -0,0 +1,109 @@
|
|||
# 크롬 Command-Line 스위치 지원
|
||||
|
||||
The following command lines switches in Chrome browser are also supported in
|
||||
Electron, you can use [app.commandLine.appendSwitch][append-switch] to append
|
||||
them in your app's main script before the [ready][ready] event of [app][app]
|
||||
module is emitted:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
app.commandLine.appendSwitch('remote-debugging-port', '8315');
|
||||
app.commandLine.appendSwitch('host-rules', 'MAP * 127.0.0.1');
|
||||
|
||||
app.on('ready', function() {
|
||||
// Your code here
|
||||
});
|
||||
```
|
||||
|
||||
## --client-certificate=`path`
|
||||
|
||||
Sets `path` of client certificate file.
|
||||
|
||||
## --ignore-connections-limit=`domains`
|
||||
|
||||
Ignore the connections limit for `domains` list seperated by `,`.
|
||||
|
||||
## --disable-http-cache
|
||||
|
||||
Disables the disk cache for HTTP requests.
|
||||
|
||||
## --remote-debugging-port=`port`
|
||||
|
||||
Enables remote debug over HTTP on the specified `port`.
|
||||
|
||||
## --proxy-server=`address:port`
|
||||
|
||||
Uses a specified proxy server, overrides system settings. This switch only
|
||||
affects HTTP and HTTPS requests.
|
||||
|
||||
## --no-proxy-server
|
||||
|
||||
Don't use a proxy server, always make direct connections. Overrides any other
|
||||
proxy server flags that are passed.
|
||||
|
||||
## --host-rules=`rules`
|
||||
|
||||
Comma-separated list of `rules` that control how hostnames are mapped.
|
||||
|
||||
For example:
|
||||
|
||||
* `MAP * 127.0.0.1` Forces all hostnames to be mapped to 127.0.0.1
|
||||
* `MAP *.google.com proxy` Forces all google.com subdomains to be resolved to
|
||||
"proxy".
|
||||
* `MAP test.com [::1]:77` Forces "test.com" to resolve to IPv6 loopback. Will
|
||||
also force the port of the resulting socket address to be 77.
|
||||
* `MAP * baz, EXCLUDE www.google.com` Remaps everything to "baz", except for
|
||||
"www.google.com".
|
||||
|
||||
These mappings apply to the endpoint host in a net request (the TCP connect
|
||||
and host resolver in a direct connection, and the `CONNECT` in an http proxy
|
||||
connection, and the endpoint host in a `SOCKS` proxy connection).
|
||||
|
||||
## --host-resolver-rules=`rules`
|
||||
|
||||
Like `--host-rules` but these `rules` only apply to the host resolver.
|
||||
|
||||
[app]: app-ko.md
|
||||
[append-switch]: app-ko.md#appcommandlineappendswitchswitch-value
|
||||
[ready]: app-ko.md#event-ready
|
||||
|
||||
## --ignore-certificate-errors
|
||||
|
||||
Ignores certificate related errors.
|
||||
|
||||
## --ppapi-flash-path=`path`
|
||||
|
||||
Sets `path` of pepper flash plugin.
|
||||
|
||||
## --ppapi-flash-version=`version`
|
||||
|
||||
Sets `version` of pepper flash plugin.
|
||||
|
||||
## --log-net-log=`path`
|
||||
|
||||
Enables saving net log events and writes them to `path`.
|
||||
|
||||
## --v=`log_level`
|
||||
|
||||
Gives the default maximal active V-logging level; 0 is the default. Normally
|
||||
positive values are used for V-logging levels.
|
||||
|
||||
Passing `--v=-1` will disable logging.
|
||||
|
||||
## --vmodule=`pattern`
|
||||
|
||||
Gives the per-module maximal V-logging levels to override the value given by
|
||||
`--v`. E.g. `my_module=2,foo*=3` would change the logging level for all code in
|
||||
source files `my_module.*` and `foo*.*`.
|
||||
|
||||
Any pattern containing a forward or backward slash will be tested against the
|
||||
whole pathname and not just the module. E.g. `*/foo/bar/*=2` would change the
|
||||
logging level for all code in source files under a `foo/bar` directory.
|
||||
|
||||
To disable all chromium related logs and only enable your application logs you
|
||||
can do:
|
||||
|
||||
```javascript
|
||||
app.commandLine.appendSwitch('v', -1);
|
||||
app.commandLine.appendSwitch('vmodule', 'console=0');
|
||||
```
|
||||
88
docs/api/clipboard-ko.md
Normal file
88
docs/api/clipboard-ko.md
Normal file
|
|
@ -0,0 +1,88 @@
|
|||
# clipboard
|
||||
|
||||
`clipboard`는 복사/붙여넣기 작업을 수행하는 방법을 제공합니다. 다음 예제는 클립보드에 문자열을 씁니다:
|
||||
|
||||
```javascript
|
||||
var clipboard = require('clipboard');
|
||||
clipboard.writeText('Example String');
|
||||
```
|
||||
|
||||
X Window 시스템에선 selection 클립보드도 존재합니다. 이를 사용하려면 인자 뒤에 `selection` 문자열을 같이 지정해주어야 합니다:
|
||||
|
||||
```javascript
|
||||
var clipboard = require('clipboard');
|
||||
clipboard.writeText('Example String', 'selection');
|
||||
console.log(clipboard.readText('selection'));
|
||||
```
|
||||
|
||||
## clipboard.readText([type])
|
||||
|
||||
* `type` String
|
||||
|
||||
클립보드 컨텐츠를 `plain text`로 반환합니다.
|
||||
|
||||
## clipboard.writeText(text[, type])
|
||||
|
||||
* `text` String
|
||||
* `type` String
|
||||
|
||||
클립보드에 `plain text`로 문자열을 씁니다.
|
||||
|
||||
## clipboard.readHtml([type])
|
||||
|
||||
* `type` String
|
||||
|
||||
클립보드 컨텐츠를 `markup`으로 반환합니다.
|
||||
|
||||
## clipboard.writeHtml(markup[, type])
|
||||
|
||||
* `markup` String
|
||||
* `type` String
|
||||
|
||||
클립보드에 `markup`으로 씁니다.
|
||||
|
||||
## clipboard.readImage([type])
|
||||
|
||||
* `type` String
|
||||
|
||||
클립보드로부터 [NativeImage](native-image-ko.md)로 이미지를 읽어들입니다.
|
||||
|
||||
## clipboard.writeImage(image[, type])
|
||||
|
||||
* `image` [NativeImage](native-image-ko.md)
|
||||
* `type` String
|
||||
|
||||
클립보드에 `image`를 씁니다.
|
||||
|
||||
## clipboard.clear([type])
|
||||
|
||||
* `type` String
|
||||
|
||||
클립보드에 저장된 모든 컨텐츠를 삭제합니다.
|
||||
|
||||
## clipboard.availableFormats([type])
|
||||
|
||||
클립보드의 `type`에 해당하는 지원하는 `format`을 문자열로 반환합니다.
|
||||
|
||||
## clipboard.has(data[, type])
|
||||
|
||||
* `data` String
|
||||
* `type` String
|
||||
|
||||
클립보드가 지정한 `data`의 형식을 지원하는지 확인합니다.
|
||||
|
||||
```javascript
|
||||
var clipboard = require('clipboard');
|
||||
console.log(clipboard.has('<p>selection</p>'));
|
||||
```
|
||||
|
||||
**알림:** 이 API는 실험적인 기능이며 차후 최신버전에서 제외될 수 있습니다.
|
||||
|
||||
## clipboard.read(data[, type])
|
||||
|
||||
* `data` String
|
||||
* `type` String
|
||||
|
||||
클립보드로부터 `data`를 읽어들입니다.
|
||||
|
||||
**알림:** 이 API는 실험적인 기능이며 차후 최신버전에서 제외될 수 있습니다.
|
||||
137
docs/api/content-tracing-ko.md
Normal file
137
docs/api/content-tracing-ko.md
Normal file
|
|
@ -0,0 +1,137 @@
|
|||
# content-tracing
|
||||
|
||||
The `content-trace` module is used to collect tracing data generated by the
|
||||
underlying Chromium content module. This module does not include a web interface
|
||||
so you need to open `chrome://tracing/` in a Chrome browser and load the generated
|
||||
file to view the result.
|
||||
|
||||
```javascript
|
||||
var tracing = require('content-tracing');
|
||||
tracing.startRecording('*', tracing.DEFAULT_OPTIONS, function() {
|
||||
console.log('Tracing started');
|
||||
|
||||
setTimeout(function() {
|
||||
tracing.stopRecording('', function(path) {
|
||||
console.log('Tracing data recorded to ' + path);
|
||||
});
|
||||
}, 5000);
|
||||
});
|
||||
```
|
||||
|
||||
## tracing.getCategories(callback)
|
||||
|
||||
* `callback` Function
|
||||
|
||||
Get a set of category groups. The category groups can change as new code paths
|
||||
are reached.
|
||||
|
||||
Once all child processes have acked to the `getCategories` request, `callback`
|
||||
is invoked with an array of category groups.
|
||||
|
||||
## tracing.startRecording(categoryFilter, options, callback)
|
||||
|
||||
* `categoryFilter` String
|
||||
* `options` Integer
|
||||
* `callback` Function
|
||||
|
||||
Start recording on all processes.
|
||||
|
||||
Recording begins immediately locally, and asynchronously on child processes
|
||||
as soon as they receive the EnableRecording request. Once all child processes
|
||||
have acked to the `startRecording` request, `callback` will be called back.
|
||||
|
||||
`categoryFilter` is a filter to control what category groups should be
|
||||
traced. A filter can have an optional `-` prefix to exclude category groups
|
||||
that contain a matching category. Having both included and excluded
|
||||
category patterns in the same list is not supported.
|
||||
|
||||
Examples:
|
||||
|
||||
* `test_MyTest*`,
|
||||
* `test_MyTest*,test_OtherStuff`,
|
||||
* `"-excluded_category1,-excluded_category2`
|
||||
|
||||
`options` controls what kind of tracing is enabled, it could be a OR-ed
|
||||
combination of `tracing.DEFAULT_OPTIONS`, `tracing.ENABLE_SYSTRACE`,
|
||||
`tracing.ENABLE_SAMPLING` and `tracing.RECORD_CONTINUOUSLY`.
|
||||
|
||||
## tracing.stopRecording(resultFilePath, callback)
|
||||
|
||||
* `resultFilePath` String
|
||||
* `callback` Function
|
||||
|
||||
Stop recording on all processes.
|
||||
|
||||
Child processes typically are caching trace data and only rarely flush and send
|
||||
trace data back to the main process. That is because it may be an expensive
|
||||
operation to send the trace data over IPC, and we would like to avoid much
|
||||
runtime overhead of tracing. So, to end tracing, we must asynchronously ask all
|
||||
child processes to flush any pending trace data.
|
||||
|
||||
Once all child processes have acked to the `stopRecording` request, `callback`
|
||||
will be called back with a file that contains the traced data.
|
||||
|
||||
Trace data will be written into `resultFilePath` if it is not empty, or into a
|
||||
temporary file. The actual file path will be passed to `callback` if it's not
|
||||
null.
|
||||
|
||||
## tracing.startMonitoring(categoryFilter, options, callback)
|
||||
|
||||
* `categoryFilter` String
|
||||
* `options` Integer
|
||||
* `callback` Function
|
||||
|
||||
Start monitoring on all processes.
|
||||
|
||||
Monitoring begins immediately locally, and asynchronously on child processes as
|
||||
soon as they receive the `startMonitoring` request.
|
||||
|
||||
Once all child processes have acked to the `startMonitoring` request,
|
||||
`callback` will be called back.
|
||||
|
||||
## tracing.stopMonitoring(callback);
|
||||
|
||||
* `callback` Function
|
||||
|
||||
Stop monitoring on all processes.
|
||||
|
||||
Once all child processes have acked to the `stopMonitoring` request, `callback`
|
||||
is called back.
|
||||
|
||||
## tracing.captureMonitoringSnapshot(resultFilePath, callback)
|
||||
|
||||
* `resultFilePath` String
|
||||
* `callback` Function
|
||||
|
||||
Get the current monitoring traced data.
|
||||
|
||||
Child processes typically are caching trace data and only rarely flush and send
|
||||
trace data back to the main process. That is because it may be an expensive
|
||||
operation to send the trace data over IPC, and we would like to avoid unneeded
|
||||
runtime overhead of tracing. So, to end tracing, we must asynchronously ask all
|
||||
child processes to flush any pending trace data.
|
||||
|
||||
Once all child processes have acked to the `captureMonitoringSnapshot` request,
|
||||
the `callback` will be invoked with a file that contains the traced data.
|
||||
|
||||
|
||||
## tracing.getTraceBufferUsage(callback)
|
||||
|
||||
* `callback` Function
|
||||
|
||||
Get the maximum across processes of trace buffer percent full state. When the
|
||||
TraceBufferUsage value is determined, the `callback` is called.
|
||||
|
||||
## tracing.setWatchEvent(categoryName, eventName, callback)
|
||||
|
||||
* `categoryName` String
|
||||
* `eventName` String
|
||||
* `callback` Function
|
||||
|
||||
`callback` will will be called every time the given event occurs on any
|
||||
process.
|
||||
|
||||
## tracing.cancelWatchEvent()
|
||||
|
||||
Cancel the watch event. If tracing is enabled, this may race with the watch
|
||||
event callback.
|
||||
61
docs/api/crash-reporter-ko.md
Normal file
61
docs/api/crash-reporter-ko.md
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
# crash-reporter
|
||||
|
||||
An example of automatically submitting crash reporters to remote server:
|
||||
|
||||
```javascript
|
||||
crashReporter = require('crash-reporter');
|
||||
crashReporter.start({
|
||||
productName: 'YourName',
|
||||
companyName: 'YourCompany',
|
||||
submitUrl: 'https://your-domain.com/url-to-submit',
|
||||
autoSubmit: true
|
||||
});
|
||||
```
|
||||
|
||||
## crashReporter.start(options)
|
||||
|
||||
* `options` Object
|
||||
* `productName` String, default: Electron
|
||||
* `companyName` String, default: GitHub, Inc
|
||||
* `submitUrl` String, default: http://54.249.141.255:1127/post
|
||||
* URL that crash reports would be sent to as POST
|
||||
* `autoSubmit` Boolean, default: true
|
||||
* Send the crash report without user interaction
|
||||
* `ignoreSystemCrashHandler` Boolean, default: false
|
||||
* `extra` Object
|
||||
* An object you can define which content will be send along with the report.
|
||||
* Only string properties are send correctly.
|
||||
* Nested objects are not supported.
|
||||
|
||||
Developers are required to call the API before using other crashReporter APIs.
|
||||
|
||||
|
||||
**Note:** On OS X, electron uses a new `crashpad` client, which is different
|
||||
with the `breakpad` on Windows and Linux. To enable crash collection feature,
|
||||
you are required to call `crashReporter.start` API to initiliaze `crashpad` in
|
||||
main process, even you only collect crash report in renderer process.
|
||||
|
||||
## crashReporter.getLastCrashReport()
|
||||
|
||||
Returns the date and ID of last crash report, when there was no crash report
|
||||
sent or the crash reporter is not started, `null` will be returned.
|
||||
|
||||
## crashReporter.getUploadedReports()
|
||||
|
||||
Returns all uploaded crash reports, each report contains date and uploaded ID.
|
||||
|
||||
# crash-reporter payload
|
||||
|
||||
The crash reporter will send the following data to the `submitUrl` as `POST`:
|
||||
|
||||
* `rept` String - e.g. 'electron-crash-service'
|
||||
* `ver` String - The version of Electron
|
||||
* `platform` String - e.g. 'win32'
|
||||
* `process_type` String - e.g. 'renderer'
|
||||
* `ptime` Number
|
||||
* `_version` String - The version in `package.json`
|
||||
* `_productName` String - The product name in the crashReporter `options` object
|
||||
* `prod` String - Name of the underlying product. In this case Electron
|
||||
* `_companyName` String - The company name in the crashReporter `options` object
|
||||
* `upload_file_minidump` File - The crashreport as file
|
||||
* All level one properties of the `extra` object in the crashReporter `options` object
|
||||
92
docs/api/dialog-ko.md
Normal file
92
docs/api/dialog-ko.md
Normal file
|
|
@ -0,0 +1,92 @@
|
|||
# dialog
|
||||
|
||||
The `dialog` module provides APIs to show native system dialogs, so web
|
||||
applications can deliver the same user experience as native applications.
|
||||
|
||||
An example of showing a dialog to select multiple files and directories:
|
||||
|
||||
```javascript
|
||||
var win = ...; // window in which to show the dialog
|
||||
var dialog = require('dialog');
|
||||
console.log(dialog.showOpenDialog({ properties: [ 'openFile', 'openDirectory', 'multiSelections' ]}));
|
||||
```
|
||||
|
||||
**Note for OS X**: If you want to present dialogs as sheets, the only thing you have to do is provide a `BrowserWindow` reference in the `browserWindow` parameter.
|
||||
|
||||
## dialog.showOpenDialog([browserWindow], [options], [callback])
|
||||
|
||||
* `browserWindow` BrowserWindow
|
||||
* `options` Object
|
||||
* `title` String
|
||||
* `defaultPath` String
|
||||
* `filters` Array
|
||||
* `properties` Array - Contains which features the dialog should use, can
|
||||
contain `openFile`, `openDirectory`, `multiSelections` and
|
||||
`createDirectory`
|
||||
* `callback` Function
|
||||
|
||||
On success, returns an array of file paths chosen by the user, otherwise
|
||||
returns `undefined`.
|
||||
|
||||
The `filters` specifies an array of file types that can be displayed or
|
||||
selected, an example is:
|
||||
|
||||
```javascript
|
||||
{
|
||||
filters: [
|
||||
{ name: 'Images', extensions: ['jpg', 'png', 'gif'] },
|
||||
{ name: 'Movies', extensions: ['mkv', 'avi', 'mp4'] },
|
||||
{ name: 'Custom File Type', extensions: ['as'] }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
If a `callback` is passed, the API call would be asynchronous and the result
|
||||
would be passed via `callback(filenames)`
|
||||
|
||||
**Note:** On Windows and Linux, an open dialog can not be both a file selector
|
||||
and a directory selector, so if you set `properties` to
|
||||
`['openFile', 'openDirectory']` on these platforms, a directory selector will be shown.
|
||||
|
||||
## dialog.showSaveDialog([browserWindow], [options], [callback])
|
||||
|
||||
* `browserWindow` BrowserWindow
|
||||
* `options` Object
|
||||
* `title` String
|
||||
* `defaultPath` String
|
||||
* `filters` Array
|
||||
* `callback` Function
|
||||
|
||||
On success, returns the path of the file chosen by the user, otherwise returns
|
||||
`undefined`.
|
||||
|
||||
The `filters` specifies an array of file types that can be displayed, see
|
||||
`dialog.showOpenDialog` for an example.
|
||||
|
||||
If a `callback` is passed, the API call will be asynchronous and the result
|
||||
will be passed via `callback(filename)`
|
||||
|
||||
## dialog.showMessageBox([browserWindow], options, [callback])
|
||||
|
||||
* `browserWindow` BrowserWindow
|
||||
* `options` Object
|
||||
* `type` String - Can be `"none"`, `"info"` or `"warning"`
|
||||
* `buttons` Array - Array of texts for buttons
|
||||
* `title` String - Title of the message box, some platforms will not show it
|
||||
* `message` String - Content of the message box
|
||||
* `detail` String - Extra information of the message
|
||||
* `icon` [NativeImage](native-image-ko.md)
|
||||
* `callback` Function
|
||||
|
||||
Shows a message box, it will block until the message box is closed. It returns
|
||||
the index of the clicked button.
|
||||
|
||||
If a `callback` is passed, the API call will be asynchronous and the result
|
||||
will be passed via `callback(response)`
|
||||
|
||||
## dialog.showErrorBox(title, content)
|
||||
|
||||
Runs a modal dialog that shows an error message.
|
||||
|
||||
This API can be called safely before the `ready` event of `app` module emits, it
|
||||
is usually used to report errors in early stage of startup.
|
||||
28
docs/api/file-object-ko.md
Normal file
28
docs/api/file-object-ko.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# `File` 객체
|
||||
|
||||
DOM의 File 인터페이스는 네이티브 파일을 추상화 합니다. 유저가 직접적으로 HTML5 File API를 사용하여 작업할 때 파일의 경로를
|
||||
알 수 있도록 Electron은 파일시스템의 실제 파일 경로를 담은 `path` 속성을 File 인터페이스에 추가하였습니다.
|
||||
|
||||
다음 예제는 drag n drop한 파일의 실제 경로를 가져옵니다:
|
||||
|
||||
```html
|
||||
<div id="holder">
|
||||
Drag your file here
|
||||
</div>
|
||||
|
||||
<script>
|
||||
var holder = document.getElementById('holder');
|
||||
holder.ondragover = function () {
|
||||
return false;
|
||||
};
|
||||
holder.ondragleave = holder.ondragend = function () {
|
||||
return false;
|
||||
};
|
||||
holder.ondrop = function (e) {
|
||||
e.preventDefault();
|
||||
var file = e.dataTransfer.files[0];
|
||||
console.log('File you dragged here is', file.path);
|
||||
return false;
|
||||
};
|
||||
</script>
|
||||
```
|
||||
89
docs/api/frameless-window-ko.md
Normal file
89
docs/api/frameless-window-ko.md
Normal file
|
|
@ -0,0 +1,89 @@
|
|||
# Frameless window
|
||||
|
||||
A frameless window is a window that has no chrome.
|
||||
|
||||
## Create a frameless window
|
||||
|
||||
To create a frameless window, you only need to specify `frame` to `false` in
|
||||
[BrowserWindow](browser-window-ko.md)'s `options`:
|
||||
|
||||
|
||||
```javascript
|
||||
var BrowserWindow = require('browser-window');
|
||||
var win = new BrowserWindow({ width: 800, height: 600, frame: false });
|
||||
```
|
||||
|
||||
## Transparent window
|
||||
|
||||
By setting the `transparent` option to `true`, you can also make the frameless
|
||||
window transparent:
|
||||
|
||||
```javascript
|
||||
var win = new BrowserWindow({ transparent: true, frame: false });
|
||||
```
|
||||
|
||||
### Limitations
|
||||
|
||||
* You can not click through the transparent area, we are going to introduce an
|
||||
API to set window shape to solve this, but currently blocked at an
|
||||
[upstream bug](https://code.google.com/p/chromium/issues/detail?id=387234).
|
||||
* Transparent window is not resizable, setting `resizable` to `true` may make
|
||||
transparent window stop working on some platforms.
|
||||
* The `blur` filter only applies to the web page, so there is no way to apply
|
||||
blur effect to the content below the window.
|
||||
* On Windows transparent window will not work when DWM is disabled.
|
||||
* On Linux users have to put `--enable-transparent-visuals --disable-gpu` in
|
||||
command line to disable GPU and allow ARGB to make transparent window, this is
|
||||
caused by an upstream bug that [alpha channel doesn't work on some NVidia
|
||||
drivers](https://code.google.com/p/chromium/issues/detail?id=369209) on Linux.
|
||||
* On Mac the native window shadow will not show for transparent window.
|
||||
|
||||
## Draggable region
|
||||
|
||||
By default, the frameless window is non-draggable. Apps need to specify
|
||||
`-webkit-app-region: drag` in CSS to tell Electron which regions are draggable
|
||||
(like the OS's standard titlebar), and apps can also use
|
||||
`-webkit-app-region: no-drag` to exclude the non-draggable area from the
|
||||
draggable region. Note that only rectangular shape is currently supported.
|
||||
|
||||
To make the whole window draggable, you can add `-webkit-app-region: drag` as
|
||||
`body`'s style:
|
||||
|
||||
```html
|
||||
<body style="-webkit-app-region: drag">
|
||||
</body>
|
||||
```
|
||||
|
||||
And note that if you have made the whole window draggable, you must also mark
|
||||
buttons as non-draggable, otherwise it would be impossible for users to click on
|
||||
them:
|
||||
|
||||
```css
|
||||
button {
|
||||
-webkit-app-region: no-drag;
|
||||
}
|
||||
```
|
||||
|
||||
If you're only using a custom titlebar, you also need to make buttons in
|
||||
titlebar non-draggable.
|
||||
|
||||
## Text selection
|
||||
|
||||
One thing on frameless window is that the dragging behaviour may conflict with
|
||||
selecting text, for example, when you drag the titlebar, you may accidentally
|
||||
select the text on titlebar. To prevent this, you need to disable text
|
||||
selection on dragging area like this:
|
||||
|
||||
```css
|
||||
.titlebar {
|
||||
-webkit-user-select: none;
|
||||
-webkit-app-region: drag;
|
||||
}
|
||||
```
|
||||
|
||||
## Context menu
|
||||
|
||||
On some platforms, the draggable area would be treated as non-client frame, so
|
||||
when you right click on it a system menu would be popuped. To make context menu
|
||||
behave correctly on all platforms, you should never custom context menu on
|
||||
draggable areas.
|
||||
47
docs/api/global-shortcut-ko.md
Normal file
47
docs/api/global-shortcut-ko.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
# global-shortcut
|
||||
|
||||
`global-shortcut` 모듈은 사용자가 다양한 단축키 작업을 정의 할 수 있도록 운영체제의 전역 키보드 단축키를 설정 등록/해제 하는 방법을 제공합니다.
|
||||
참고로 설정된 단축키는 어플리케이션이 백그라운드로 작동(창이 포커스 되지 않음) 할 때도 여전히 계속 작동합니다.
|
||||
|
||||
```javascript
|
||||
var globalShortcut = require('global-shortcut');
|
||||
|
||||
// 'ctrl+x' 단축키를 리스너에 등록합니다.
|
||||
var ret = globalShortcut.register('ctrl+x', function() { console.log('ctrl+x is pressed'); })
|
||||
|
||||
if (!ret) {
|
||||
console.log('registration failed');
|
||||
}
|
||||
|
||||
// 단축키가 등록되었는지 확인합니다.
|
||||
console.log(globalShortcut.isRegistered('ctrl+x'));
|
||||
|
||||
// 단축키의 등록을 해제합니다.
|
||||
globalShortcut.unregister('ctrl+x');
|
||||
|
||||
// 모든 단축키의 등록을 해제합니다.
|
||||
globalShortcut.unregisterAll();
|
||||
```
|
||||
|
||||
## globalShortcut.register(accelerator, callback)
|
||||
|
||||
* `accelerator` [Accelerator](accelerator-ko.md)
|
||||
* `callback` Function
|
||||
|
||||
`accelerator`로 표현된 전역 단축키를 등록합니다. 유저로부터 등록된 단축키가 눌렸을 경우 `callback` 함수가 호출됩니다.
|
||||
|
||||
## globalShortcut.isRegistered(accelerator)
|
||||
|
||||
* `accelerator` [Accelerator](accelerator-ko.md)
|
||||
|
||||
지정된 `accelerator` 단축키가 등록되었는지 여부를 확인합니다. 반환값은 boolean(true, false) 입니다.
|
||||
|
||||
## globalShortcut.unregister(accelerator)
|
||||
|
||||
* `accelerator` [Accelerator](accelerator-ko.md)
|
||||
|
||||
`키코드`에 해당하는 전역 단축키를 등록 해제합니다.
|
||||
|
||||
## globalShortcut.unregisterAll()
|
||||
|
||||
모든 전역 단축키 등록을 해제합니다.
|
||||
46
docs/api/ipc-main-process-ko.md
Normal file
46
docs/api/ipc-main-process-ko.md
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
# ipc (main process)
|
||||
|
||||
랜더러 프로세스(웹 페이지)로 부터 동기 또는 비동기로 메시지를 받아 처리합니다.
|
||||
|
||||
랜더러로부터 발신된 메시지들은 모두 이 모듈에서 `channel` 이라는 특정 이벤트 이름을 통해 수신할 수 있습니다.
|
||||
동기 메시지는 `event.returnValue`를 이용하여 반환값(답장)을 설정할 수 있습니다. 비동기 메시지라면 `event.sender.send(...)`를 사용하면 됩니다.
|
||||
|
||||
또한 메인 프로세스에서 랜더러 프로세스로 메시지를 보내는 것도 가능합니다.
|
||||
자세한 내용은 [WebContents.send](browser-window-ko.md#webcontentssendchannel-args)를 참고 하세요.
|
||||
|
||||
보내진 메시지들을 처리하는 예제입니다:
|
||||
|
||||
```javascript
|
||||
// 메인 프로세스에서 처리.
|
||||
var ipc = require('ipc');
|
||||
ipc.on('asynchronous-message', function(event, arg) {
|
||||
console.log(arg); // prints "ping"
|
||||
event.sender.send('asynchronous-reply', 'pong');
|
||||
});
|
||||
|
||||
ipc.on('synchronous-message', function(event, arg) {
|
||||
console.log(arg); // prints "ping"
|
||||
event.returnValue = 'pong';
|
||||
});
|
||||
```
|
||||
|
||||
```javascript
|
||||
// 랜더러 프로세스에서의 처리 (web page).
|
||||
var ipc = require('ipc');
|
||||
console.log(ipc.sendSync('synchronous-message', 'ping')); // prints "pong"
|
||||
|
||||
ipc.on('asynchronous-reply', function(arg) {
|
||||
console.log(arg); // prints "pong"
|
||||
});
|
||||
ipc.send('asynchronous-message', 'ping');
|
||||
```
|
||||
|
||||
## Class: Event
|
||||
|
||||
### Event.returnValue
|
||||
|
||||
동기 메시지를 설정합니다.
|
||||
|
||||
### Event.sender
|
||||
|
||||
메시지를 보내온 sender `WebContents` 객체입니다.
|
||||
25
docs/api/ipc-renderer-ko.md
Normal file
25
docs/api/ipc-renderer-ko.md
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
# ipc (renderer)
|
||||
|
||||
`ipc` 모듈은 메인 프로세스로 메시지를 동기 또는 비동기로 보내고 받을 수 있는 몇 가지 방법을 제공합니다.
|
||||
만약 랜더러 프로세스에서 메인 프로세스의 모듈을 직접적으로 사용하고 싶다면 [remote](remote-ko.md) 모듈을 사용하는 것을 고려해보는 것이 좋습니다.
|
||||
|
||||
[ipc (main process)](ipc-main-process-ko.md)에서 예제를 볼 수 있습니다.
|
||||
|
||||
## ipc.send(channel[, args...])
|
||||
|
||||
지정한 `channel`을 통해 `args..`를 비동기로 메시지를 보냅니다. 메인 프로세스는 `ipc` 모듈의 `channel` 이벤트를 통해 메시지를 받을 수 있습니다.
|
||||
|
||||
## ipc.sendSync(channel[, args...])
|
||||
|
||||
지정한 `channel`을 통해 `args..`를 동기로 메시지를 보냅니다. 그리고 메인 프로세스에서 보낸 결과를 반환합니다.
|
||||
메인 프로세스는 `ipc` 모듈의 `channel` 이벤트를 통해 메시지를 받을 수 있습니다. 그리고 `event.returnValue`를 통해 반환값을 설정할 수 있습니다.
|
||||
|
||||
역자 주: `channel`은 이벤트 이름입니다.
|
||||
|
||||
**알림:** 보통 개발자들은 해당 API를 사용하려 하지 않습니다. 동기 ipc 작업은 랜더러 프로세스의 모든 작업을 중단시킵니다.
|
||||
|
||||
## ipc.sendToHost(channel[, args...])
|
||||
|
||||
`ipc.send`와 비슷하지만 메시지를 메인 프로세스 대신 호스트 페이지로 보냅니다.
|
||||
|
||||
이 메소드는 보통 `<webview>`와 호스트 페이지 간의 통신에 사용됩니다.
|
||||
|
|
@ -1,20 +1,20 @@
|
|||
# menu-item
|
||||
# menu-item
|
||||
|
||||
## Class: MenuItem
|
||||
|
||||
### new MenuItem(options)
|
||||
|
||||
* `options` Object
|
||||
* `click` Function - 메뉴 아이템이 클릭될 때 호출되는 콜백함수
|
||||
* `selector` String - First Responder가 클릭될 때 호출 되는 선택자 (OS X 전용)
|
||||
* `type` String - `MenuItem`의 타입 `normal`, `separator`, `submenu`, `checkbox` 또는 `radio` 사용가능
|
||||
* `click` Function - 메뉴 아이템이 클릭될 때 호출되는 콜백함수
|
||||
* `selector` String - First Responder가 클릭될 때 호출 되는 선택자 (OS X 전용)
|
||||
* `type` String - `MenuItem`의 타입 `normal`, `separator`, `submenu`, `checkbox` 또는 `radio` 사용가능
|
||||
* `label` String
|
||||
* `sublabel` String
|
||||
* `accelerator` [Accelerator](accelerator.md)
|
||||
* `icon` [NativeImage](native-image.md)
|
||||
* `accelerator` [Accelerator](accelerator-ko.md)
|
||||
* `icon` [NativeImage](native-image-ko.md)
|
||||
* `enabled` Boolean
|
||||
* `visible` Boolean
|
||||
* `checked` Boolean
|
||||
* `submenu` Menu - 보조메뉴를 설정합니다. `type`이 `submenu`일 경우 반드시 설정해야합니다. 일반 메뉴 아이템일 경우 생략할 수 있습니다.
|
||||
* `id` String - 현재 메뉴 아이템에 대해 유일키를 지정합니다. 이 키는 이후 `position` 옵션에서 사용할 수 있습니다.
|
||||
* `position` String - 미리 지정한 `id`를 이용하여 메뉴 아이템의 위치를 세밀하게 조정합니다.
|
||||
* `submenu` Menu - 보조메뉴를 설정합니다. `type`이 `submenu`일 경우 반드시 설정해야합니다. 일반 메뉴 아이템일 경우 생략할 수 있습니다.
|
||||
* `id` String - 현재 메뉴 아이템에 대해 유일키를 지정합니다. 이 키는 이후 `position` 옵션에서 사용할 수 있습니다.
|
||||
* `position` String - 미리 지정한 `id`를 이용하여 메뉴 아이템의 위치를 세밀하게 조정합니다.
|
||||
|
|
|
|||
330
docs/api/menu-ko.md
Normal file
330
docs/api/menu-ko.md
Normal file
|
|
@ -0,0 +1,330 @@
|
|||
# menu
|
||||
|
||||
The `Menu` class is used to create native menus that can be used as
|
||||
application menus and context menus. Each menu consists of multiple menu
|
||||
items, and each menu item can have a submenu.
|
||||
|
||||
Below is an example of creating a menu dynamically in a web page by using
|
||||
the [remote](remote-ko.md) module, and showing it when the user right clicks
|
||||
the page:
|
||||
|
||||
```html
|
||||
<!-- index.html -->
|
||||
<script>
|
||||
var remote = require('remote');
|
||||
var Menu = remote.require('menu');
|
||||
var MenuItem = remote.require('menu-item');
|
||||
|
||||
var menu = new Menu();
|
||||
menu.append(new MenuItem({ label: 'MenuItem1', click: function() { console.log('item 1 clicked'); } }));
|
||||
menu.append(new MenuItem({ type: 'separator' }));
|
||||
menu.append(new MenuItem({ label: 'MenuItem2', type: 'checkbox', checked: true }));
|
||||
|
||||
window.addEventListener('contextmenu', function (e) {
|
||||
e.preventDefault();
|
||||
menu.popup(remote.getCurrentWindow());
|
||||
}, false);
|
||||
</script>
|
||||
```
|
||||
|
||||
Another example of creating the application menu with the simple template API:
|
||||
|
||||
```html
|
||||
<!-- index.html -->
|
||||
<script>
|
||||
var remote = require('remote');
|
||||
var Menu = remote.require('menu');
|
||||
var template = [
|
||||
{
|
||||
label: 'Electron',
|
||||
submenu: [
|
||||
{
|
||||
label: 'About Electron',
|
||||
selector: 'orderFrontStandardAboutPanel:'
|
||||
},
|
||||
{
|
||||
type: 'separator'
|
||||
},
|
||||
{
|
||||
label: 'Services',
|
||||
submenu: []
|
||||
},
|
||||
{
|
||||
type: 'separator'
|
||||
},
|
||||
{
|
||||
label: 'Hide Electron',
|
||||
accelerator: 'Command+H',
|
||||
selector: 'hide:'
|
||||
},
|
||||
{
|
||||
label: 'Hide Others',
|
||||
accelerator: 'Command+Shift+H',
|
||||
selector: 'hideOtherApplications:'
|
||||
},
|
||||
{
|
||||
label: 'Show All',
|
||||
selector: 'unhideAllApplications:'
|
||||
},
|
||||
{
|
||||
type: 'separator'
|
||||
},
|
||||
{
|
||||
label: 'Quit',
|
||||
accelerator: 'Command+Q',
|
||||
selector: 'terminate:'
|
||||
},
|
||||
]
|
||||
},
|
||||
{
|
||||
label: 'Edit',
|
||||
submenu: [
|
||||
{
|
||||
label: 'Undo',
|
||||
accelerator: 'Command+Z',
|
||||
selector: 'undo:'
|
||||
},
|
||||
{
|
||||
label: 'Redo',
|
||||
accelerator: 'Shift+Command+Z',
|
||||
selector: 'redo:'
|
||||
},
|
||||
{
|
||||
type: 'separator'
|
||||
},
|
||||
{
|
||||
label: 'Cut',
|
||||
accelerator: 'Command+X',
|
||||
selector: 'cut:'
|
||||
},
|
||||
{
|
||||
label: 'Copy',
|
||||
accelerator: 'Command+C',
|
||||
selector: 'copy:'
|
||||
},
|
||||
{
|
||||
label: 'Paste',
|
||||
accelerator: 'Command+V',
|
||||
selector: 'paste:'
|
||||
},
|
||||
{
|
||||
label: 'Select All',
|
||||
accelerator: 'Command+A',
|
||||
selector: 'selectAll:'
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
label: 'View',
|
||||
submenu: [
|
||||
{
|
||||
label: 'Reload',
|
||||
accelerator: 'Command+R',
|
||||
click: function() { remote.getCurrentWindow().reload(); }
|
||||
},
|
||||
{
|
||||
label: 'Toggle DevTools',
|
||||
accelerator: 'Alt+Command+I',
|
||||
click: function() { remote.getCurrentWindow().toggleDevTools(); }
|
||||
},
|
||||
]
|
||||
},
|
||||
{
|
||||
label: 'Window',
|
||||
submenu: [
|
||||
{
|
||||
label: 'Minimize',
|
||||
accelerator: 'Command+M',
|
||||
selector: 'performMiniaturize:'
|
||||
},
|
||||
{
|
||||
label: 'Close',
|
||||
accelerator: 'Command+W',
|
||||
selector: 'performClose:'
|
||||
},
|
||||
{
|
||||
type: 'separator'
|
||||
},
|
||||
{
|
||||
label: 'Bring All to Front',
|
||||
selector: 'arrangeInFront:'
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
label: 'Help',
|
||||
submenu: []
|
||||
}
|
||||
];
|
||||
|
||||
menu = Menu.buildFromTemplate(template);
|
||||
|
||||
Menu.setApplicationMenu(menu);
|
||||
</script>
|
||||
```
|
||||
|
||||
## Class: Menu
|
||||
|
||||
### new Menu()
|
||||
|
||||
Creates a new menu.
|
||||
|
||||
### Class Method: Menu.setApplicationMenu(menu)
|
||||
|
||||
* `menu` Menu
|
||||
|
||||
Sets `menu` as the application menu on OS X. On Windows and Linux, the `menu`
|
||||
will be set as each window's top menu.
|
||||
|
||||
### Class Method: Menu.sendActionToFirstResponder(action)
|
||||
|
||||
* `action` String
|
||||
|
||||
Sends the `action` to the first responder of application, this is used for
|
||||
emulating default Cocoa menu behaviors, usually you would just use the
|
||||
`selector` property of `MenuItem`.
|
||||
|
||||
**Note:** This method is OS X only.
|
||||
|
||||
### Class Method: Menu.buildFromTemplate(template)
|
||||
|
||||
* `template` Array
|
||||
|
||||
Generally, the `template` is just an array of `options` for constructing
|
||||
[MenuItem](menu-item-ko.md), the usage can be referenced above.
|
||||
|
||||
You can also attach other fields to element of the `template`, and they will
|
||||
become properties of the constructed menu items.
|
||||
|
||||
### Menu.popup(browserWindow, [x, y])
|
||||
|
||||
* `browserWindow` BrowserWindow
|
||||
* `x` Number
|
||||
* `y` Number
|
||||
|
||||
Popups this menu as a context menu in the `browserWindow`. You can optionally
|
||||
provide a `(x,y)` coordinate to place the menu at, otherwise it will be placed
|
||||
at the current mouse cursor position.
|
||||
|
||||
### Menu.append(menuItem)
|
||||
|
||||
* `menuItem` MenuItem
|
||||
|
||||
Appends the `menuItem` to the menu.
|
||||
|
||||
### Menu.insert(pos, menuItem)
|
||||
|
||||
* `pos` Integer
|
||||
* `menuItem` MenuItem
|
||||
|
||||
Inserts the `menuItem` to the `pos` position of the menu.
|
||||
|
||||
### Menu.items
|
||||
|
||||
Get the array containing the menu's items.
|
||||
|
||||
## Notes on OS X application menu
|
||||
|
||||
OS X has a completely different style of application menu from Windows and
|
||||
Linux, and here are some notes on making your app's menu more native-like.
|
||||
|
||||
### Standard menus
|
||||
|
||||
On OS X there are many system defined standard menus, like the `Services` and
|
||||
`Windows` menus. To make your menu a standard menu, you can just set your menu's
|
||||
label to one of followings, and Electron will recognize them and make them
|
||||
become standard menus:
|
||||
|
||||
* `Window`
|
||||
* `Help`
|
||||
* `Services`
|
||||
|
||||
### Standard menu item actions
|
||||
|
||||
OS X has provided standard actions for some menu items (which are called
|
||||
`selector`s), like `About xxx`, `Hide xxx`, and `Hide Others`. To set the action
|
||||
of a menu item to a standard action, you can set the `selector` attribute of the
|
||||
menu item.
|
||||
|
||||
### Main menu's name
|
||||
|
||||
On OS X the label of application menu's first item is always your app's name,
|
||||
no matter what label you set. To change it you have to change your app's name
|
||||
by modifying your app bundle's `Info.plist` file. See
|
||||
[About Information Property List Files](https://developer.apple.com/library/ios/documentation/general/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html)
|
||||
for more.
|
||||
|
||||
|
||||
## Menu item position
|
||||
|
||||
You can make use of `position` and `id` to control how the item would be placed
|
||||
when building a menu with `Menu.buildFromTemplate`.
|
||||
|
||||
The `position` attribute of `MenuItem` has the form `[placement]=[id]` where
|
||||
placement is one of `before`, `after`, or `endof` and `id` is the unique ID of
|
||||
an existing item in the menu:
|
||||
|
||||
* `before` - Inserts this item before the id referenced item. If the
|
||||
referenced item doesn't exist the item will be inserted at the end of
|
||||
the menu.
|
||||
* `after` - Inserts this item after id referenced item. If the referenced
|
||||
item doesn't exist the item will be inserted at the end of the menu.
|
||||
* `endof` - Inserts this item at the end of the logical group containing
|
||||
the id referenced item. (Groups are created by separator items). If
|
||||
the referenced item doesn't exist a new separator group is created with
|
||||
the given id and this item is inserted after that separator.
|
||||
|
||||
When an item is positioned following unpositioned items are inserted after
|
||||
it, until a new item is positioned. So if you want to position a group of
|
||||
menu items in the same location you only need to specify a position for
|
||||
the first item.
|
||||
|
||||
### Examples
|
||||
|
||||
Template:
|
||||
|
||||
```javascript
|
||||
[
|
||||
{label: '4', id: '4'},
|
||||
{label: '5', id: '5'},
|
||||
{label: '1', id: '1', position: 'before=4'},
|
||||
{label: '2', id: '2'},
|
||||
{label: '3', id: '3'}
|
||||
]
|
||||
```
|
||||
|
||||
Menu:
|
||||
|
||||
```
|
||||
- 1
|
||||
- 2
|
||||
- 3
|
||||
- 4
|
||||
- 5
|
||||
```
|
||||
|
||||
Template:
|
||||
|
||||
```javascript
|
||||
[
|
||||
{label: 'a', position: 'endof=letters'},
|
||||
{label: '1', position: 'endof=numbers'},
|
||||
{label: 'b', position: 'endof=letters'},
|
||||
{label: '2', position: 'endof=numbers'},
|
||||
{label: 'c', position: 'endof=letters'},
|
||||
{label: '3', position: 'endof=numbers'}
|
||||
]
|
||||
```
|
||||
|
||||
Menu:
|
||||
|
||||
```
|
||||
- ---
|
||||
- a
|
||||
- b
|
||||
- c
|
||||
- ---
|
||||
- 1
|
||||
- 2
|
||||
- 3
|
||||
```
|
||||
127
docs/api/native-image-ko.md
Normal file
127
docs/api/native-image-ko.md
Normal file
|
|
@ -0,0 +1,127 @@
|
|||
# NativeImage
|
||||
|
||||
Electron은 파일 경로나 `NativeImage` 인스턴스를 전달하여 사용하는 이미지 API를 가지고 있습니다. `null`을 전달할 경우 빈 이미지가 사용됩니다.
|
||||
|
||||
예를 들어 트레이 메뉴를 만들거나 윈도우의 아이콘을 설정할 때 다음과 같이 `문자열`인 파일 경로를 전달할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var appIcon = new Tray('/Users/somebody/images/icon.png');
|
||||
var window = new BrowserWindow({icon: '/Users/somebody/images/window.png'});
|
||||
```
|
||||
|
||||
또는 클립보드로부터 이미지를 읽어올 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var clipboard = require('clipboard');
|
||||
var image = clipboard.readImage();
|
||||
var appIcon = new Tray(image);
|
||||
```
|
||||
|
||||
## 지원하는 포맷
|
||||
|
||||
현재 `PNG` 와 `JPEG` 포맷을 지원하고 있습니다. 손실 없는 이미지 압축과 투명도 지원을 위해 `PNG` 사용을 권장합니다.
|
||||
|
||||
## 고해상도 이미지
|
||||
|
||||
플랫폼이 high-DPI를 지원하는 경우 `@2x`와 같이 이미지의 파일명 뒤에 접미사를 추가하여 고해상도 이미지로 지정할 수 있습니다.
|
||||
|
||||
예를 들어 `icon.png` 라는 기본 해상도의 이미지를 기준으로 크기를 두 배로 늘린 이미지를 `icon@2x.png`와 같이 이름을 지정하면 고해상도 이미지로 처리됩니다.
|
||||
|
||||
서로 다른 해상도(DPI)의 이미지를 지원하고 싶다면 다중 해상도의 이미지를 접미사를 붙여 한 폴더에 넣으면 됩니다. 이 이미지를 사용(로드)할 땐 접미사를 붙이지 않습니다:
|
||||
|
||||
```text
|
||||
images/
|
||||
├── icon.png
|
||||
├── icon@2x.png
|
||||
└── icon@3x.png
|
||||
```
|
||||
|
||||
|
||||
```javascript
|
||||
var appIcon = new Tray('/Users/somebody/images/icon.png');
|
||||
```
|
||||
|
||||
지원하는 DPI 접미사는 다음과 같습니다:
|
||||
|
||||
* `@1x`
|
||||
* `@1.25x`
|
||||
* `@1.33x`
|
||||
* `@1.4x`
|
||||
* `@1.5x`
|
||||
* `@1.8x`
|
||||
* `@2x`
|
||||
* `@2.5x`
|
||||
* `@3x`
|
||||
* `@4x`
|
||||
* `@5x`
|
||||
|
||||
## 템플릿 이미지
|
||||
|
||||
템플릿 이미지는 검은색과 명확한 색상(알파 채널)으로 이루어져 있습니다.
|
||||
템플릿 이미지는 단독 이미지로 사용되지 않고 다른 컨텐츠와 혼합되어 최종 외관 만드는데 사용됩니다.
|
||||
|
||||
가장 일반적으로 템플릿 이미지는 밝고 어두운 테마 색상으로 변경할 수 있는 메뉴 바 아이콘 등에 사용되고 있습니다.
|
||||
|
||||
템플릿 이미지는 Mac 운영체제만 지원합니다.
|
||||
|
||||
템플릿 이미지를 지정하려면 다음 예제와 같이 파일명에 `Template` 문자열을 추가해야 합니다:
|
||||
|
||||
* `xxxTemplate.png`
|
||||
* `xxxTemplate@2x.png`
|
||||
|
||||
## nativeImage.createEmpty()
|
||||
|
||||
빈 `NativeImage` 인스턴스를 만듭니다.
|
||||
|
||||
## nativeImage.createFromPath(path)
|
||||
|
||||
* `path` String
|
||||
|
||||
`path`로부터 이미지를 로드하여 새로운 `NativeImage` 인스턴스를 만듭니다.
|
||||
|
||||
## nativeImage.createFromBuffer(buffer[, scaleFactor])
|
||||
|
||||
* `buffer` [Buffer][buffer]
|
||||
* `scaleFactor` Double
|
||||
|
||||
`buffer`로부터 이미지를 로드하여 새로운 `NativeImage` 인스턴스를 만듭니다. `scaleFactor`는 1.0이 기본입니다.
|
||||
|
||||
## nativeImage.createFromDataUrl(dataUrl)
|
||||
|
||||
* `dataUrl` String
|
||||
|
||||
`dataUrl`로부터 이미지를 로드하여 새로운 `NativeImage` 인스턴스를 만듭니다.
|
||||
|
||||
## Class: NativeImage
|
||||
|
||||
이미지를 표현한 클래스입니다.
|
||||
|
||||
### NativeImage.toPng()
|
||||
|
||||
`PNG` 이미지를 인코딩한 데이터를 [Buffer][buffer]로 반환합니다.
|
||||
|
||||
### NativeImage.toJpeg(quality)
|
||||
|
||||
* `quality` Integer
|
||||
|
||||
`JPEG` 이미지를 인코딩한 데이터를 [Buffer][buffer]로 반환합니다.
|
||||
|
||||
### NativeImage.toDataUrl()
|
||||
|
||||
이미지의 data URL을 반환합니다.
|
||||
|
||||
### NativeImage.isEmpty()
|
||||
|
||||
이미지가 비었는지를 체크합니다.
|
||||
|
||||
### NativeImage.getSize()
|
||||
|
||||
이미지의 사이즈를 반환합니다.
|
||||
|
||||
### NativeImage.setTemplateImage(option)
|
||||
|
||||
* `option` Boolean
|
||||
|
||||
해당 이미지를 템플릿 이미지로 설정합니다.
|
||||
|
||||
[buffer]: https://iojs.org/api/buffer.html#buffer_class_buffer
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# power-monitor
|
||||
# power-monitor
|
||||
|
||||
`power-monitor` 모듈은 PC의 파워 상태를 나타냅니다. (주로 노트북 등에서 사용됩니다)
|
||||
이 모듈은 메인 프로세스에서만 사용할 수 있으며, (remote 모듈(RPC)을 사용해도 작동이 됩니다)
|
||||
|
|
|
|||
43
docs/api/power-save-blocker-ko.md
Normal file
43
docs/api/power-save-blocker-ko.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# power-save-blocker
|
||||
|
||||
`power-save-blocker` 모듈은 시스템이 저전력 모드(슬립)로 진입하는 것을 막고 앱 및 화면이 항상 활성화되어 있는 상태를 만들 수 있도록 해줍니다.
|
||||
|
||||
예제:
|
||||
|
||||
```javascript
|
||||
var powerSaveBlocker = require('power-save-blocker');
|
||||
|
||||
var id = powerSaveBlocker.start('prevent-display-sleep');
|
||||
console.log(powerSaveBlocker.isStarted(id));
|
||||
|
||||
powerSaveBlocker.stop(id);
|
||||
```
|
||||
|
||||
## powerSaveBlocker.start(type)
|
||||
|
||||
* `type` String - Power save blocker 종류
|
||||
* `prevent-app-suspension` - 저전력 모드 등으로 인한 어플리케이션 작동 중단을 방지합니다.
|
||||
시스템을 항시 활성화 상태로 만듭니다, 하지만 화면은 자동으로 꺼질 수 있습니다. 사용 예시: 파일 다운로드, 음악 재생 등.
|
||||
* `prevent-display-sleep`- 슬립 모드 등으로 인한 어플리케이션의 작동 중단을 방지합니다.
|
||||
시스템을 항시 활성화 상태로 만들고 슬립 모드(화면 꺼짐)를 방지합니다. 사용 예시: 비디오 재생 등.
|
||||
|
||||
Power save blocker를 시작하고 시스템이 저전력 모드(슬립)로 진입하는 것을 막습니다. 정수로 된 식별 ID를 반환합니다.
|
||||
|
||||
**알림:**
|
||||
`prevent-display-sleep` 모드는 `prevent-app-suspension` 보다 우선순위가 높습니다.
|
||||
가장 높은 우선순위의 모드만 작동합니다. 다시 말해 `prevent-display-sleep` 모드는 언제나 `prevent-app-suspension` 모드의 효과를 덮어씌웁니다.
|
||||
|
||||
예를 들어 A-요청이 `prevent-app-suspension` 모드를 사용하고 B-요청이 `prevent-display-sleep`를 사용하는 API 호출이 있었다 치면
|
||||
`prevent-display-sleep` 모드를 사용하는 B의 작동이 중단(stop)되기 전까지 작동하다 B가 중단되면 `prevent-app-suspension` 모드를 사용하는 A가 작동하기 시작합니다.
|
||||
|
||||
## powerSaveBlocker.stop(id)
|
||||
|
||||
* `id` Integer - `powerSaveBlocker.start`로 부터 반환되는 power save blocker 식별 ID.
|
||||
|
||||
설정한 power save blocker를 중지합니다.
|
||||
|
||||
## powerSaveBlocker.isStarted(id)
|
||||
|
||||
* `id` Integer - `powerSaveBlocker.start`로 부터 반환되는 power save blocker 식별 ID.
|
||||
|
||||
해당하는 id의 `powerSaveBlocker`가 실행중인지 확인합니다.
|
||||
12
docs/api/process-ko.md
Normal file
12
docs/api/process-ko.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
# 프로세스 객체
|
||||
|
||||
Electron의 `process` 객체는 기존의 node와는 달리 약간의 차이점이 있습니다:
|
||||
|
||||
* `process.type` String - 프로세스의 타입, `browser` (메인 프로세스) 또는 `renderer`가 됩니다.
|
||||
* `process.versions['electron']` String - Electron의 버전.
|
||||
* `process.versions['chrome']` String - Chromium의 버전.
|
||||
* `process.resourcesPath` String - JavaScript 소스코드의 경로.
|
||||
|
||||
## process.hang
|
||||
|
||||
현재 프로세스의 주 스레드를 중단시킵니다.
|
||||
114
docs/api/protocol-ko.md
Normal file
114
docs/api/protocol-ko.md
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
# protocol
|
||||
|
||||
`protocol` 모듈은 여러 프로토콜의 요청과 응답을 커스터마이즈 할 수 있도록 이미 있는 프로토콜을 변경하거나 새로운 프로토콜을 만드는 방법을 제공합니다.
|
||||
|
||||
다음 예제는 `file://` 프로토콜과 같은 일을 하는 커스텀 프로토콜을 설정합니다:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
var path = require('path');
|
||||
|
||||
app.on('ready', function() {
|
||||
var protocol = require('protocol');
|
||||
protocol.registerProtocol('atom', function(request) {
|
||||
var url = request.url.substr(7)
|
||||
return new protocol.RequestFileJob(path.normalize(__dirname + '/' + url));
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
**알림:** 이 모듈은 app의 `ready` 이벤트가 발생한 이후에만 사용할 수 있습니다.
|
||||
|
||||
## protocol.registerProtocol(scheme, handler)
|
||||
|
||||
* `scheme` String
|
||||
* `handler` Function
|
||||
|
||||
지정한 `scheme`을 기반으로 커스텀 프로토콜을 등록합니다. 등록한 `scheme` 프로토콜에 요청이 들어올 경우 `request` 인자와 함께 `handler` 함수가 호출됩니다.
|
||||
|
||||
호출된 `handler` 함수에선 요청에 대한 해당 프로토콜의 작업 결과를 응답(반환) 해야 할 필요가 있습니다.
|
||||
|
||||
## protocol.unregisterProtocol(scheme)
|
||||
|
||||
* `scheme` String
|
||||
|
||||
지정한 `scheme` 프로토콜을 등록 해제합니다.
|
||||
|
||||
## protocol.registerStandardSchemes(value)
|
||||
|
||||
* `value` Array
|
||||
|
||||
지정한 `value` 배열을 사용하여 미리 지정된 스킴으로 등록합니다.
|
||||
|
||||
## protocol.isHandledProtocol(scheme)
|
||||
|
||||
* `scheme` String
|
||||
|
||||
해당 `scheme`에 처리자(handler)가 등록되었는지 확인합니다.
|
||||
|
||||
## protocol.interceptProtocol(scheme, handler)
|
||||
|
||||
* `scheme` String
|
||||
* `handler` Function
|
||||
|
||||
지정한 `scheme`의 작업을 `handler`로 변경합니다.
|
||||
`handler`에서 `null` 또는 `undefined`를 반환 할 경우 해당 프로토콜의 기본 동작(응답)으로 대체 됩니다.
|
||||
|
||||
## protocol.uninterceptProtocol(scheme)
|
||||
|
||||
* `scheme` String
|
||||
|
||||
변경된 프로토콜의 작업을 해제합니다.
|
||||
|
||||
## Class: protocol.RequestFileJob(path)
|
||||
|
||||
* `path` String
|
||||
|
||||
`path` 경로를 기반으로 파일을 반환하는 request 작업을 생성합니다. 그리고 해당 파일에 상응하는 mime type을 지정합니다.
|
||||
|
||||
## Class: protocol.RequestStringJob(options)
|
||||
|
||||
* `options` Object
|
||||
* `mimeType` String - `text/plain`이 기본
|
||||
* `charset` String - `UTF-8`이 기본
|
||||
* `data` String
|
||||
|
||||
문자열을 반환하는 request 작업을 생성합니다.
|
||||
|
||||
## Class: protocol.RequestBufferJob(options)
|
||||
|
||||
* `options` Object
|
||||
* `mimeType` String - Default is `application/octet-stream`
|
||||
* `encoding` String - Default is `UTF-8`
|
||||
* `data` Buffer
|
||||
|
||||
버퍼를 반환하는 request 작업을 생성합니다.
|
||||
|
||||
## Class: protocol.RequestHttpJob(options)
|
||||
|
||||
* `options` Object
|
||||
* `url` String
|
||||
* `method` String - Default is `GET`
|
||||
* `referrer` String
|
||||
|
||||
`url`의 요청 결과를 그대로 반환하는 request 작업을 생성합니다.
|
||||
|
||||
## Class: protocol.RequestErrorJob(code)
|
||||
|
||||
* `code` Integer
|
||||
|
||||
콘솔에 특정한 네트워크 에러 메시지를 설정하는 request 작업을 생성합니다.
|
||||
기본 메시지는 `net::ERR_NOT_IMPLEMENTED`입니다. 사용할 수 있는 코드의 범위는 다음과 같습니다.
|
||||
|
||||
* 범위:
|
||||
* 0- 99 System related errors
|
||||
* 100-199 Connection related errors
|
||||
* 200-299 Certificate errors
|
||||
* 300-399 HTTP errors
|
||||
* 400-499 Cache errors
|
||||
* 500-599 ?
|
||||
* 600-699 FTP errors
|
||||
* 700-799 Certificate manager errors
|
||||
* 800-899 DNS resolver errors
|
||||
|
||||
에러 코드와 메시지에 대해 자세하게 알아보려면 [네트워크 에러 리스트](https://code.google.com/p/chromium/codesearch#chromium/src/net/base/net_error_list.h)를 참고하기 바랍니다.
|
||||
159
docs/api/remote-ko.md
Normal file
159
docs/api/remote-ko.md
Normal file
|
|
@ -0,0 +1,159 @@
|
|||
# remote
|
||||
|
||||
The `remote` module provides a simple way to do inter-process communication
|
||||
between the renderer process and the main process.
|
||||
|
||||
In Electron, only GUI-unrelated modules are available in the renderer process.
|
||||
Without the `remote` module, users who wanted to call a main process API in
|
||||
the renderer process would have to explicitly send inter-process messages
|
||||
to the main process. With the `remote` module, users can invoke methods of
|
||||
main process object without explicitly sending inter-process messages,
|
||||
similar to Java's
|
||||
[RMI](http://en.wikipedia.org/wiki/Java_remote_method_invocation).
|
||||
|
||||
An example of creating a browser window in renderer process:
|
||||
|
||||
```javascript
|
||||
var remote = require('remote');
|
||||
var BrowserWindow = remote.require('browser-window');
|
||||
var win = new BrowserWindow({ width: 800, height: 600 });
|
||||
win.loadUrl('https://github.com');
|
||||
```
|
||||
|
||||
Note: for the reverse (access renderer process from main process), you can use [webContents.executeJavascript](https://github.com/atom/electron/blob/master/docs/api/browser-window-ko.md#browserwindowwebcontents).
|
||||
|
||||
## Remote objects
|
||||
|
||||
Each object (including functions) returned by the `remote` module represents an
|
||||
object in the main process (we call it a remote object or remote function).
|
||||
When you invoke methods of a remote object, call a remote function, or create
|
||||
a new object with the remote constructor (function), you are actually sending
|
||||
synchronous inter-process messages.
|
||||
|
||||
In the example above, both `BrowserWindow` and `win` were remote objects and
|
||||
`new BrowserWindow` didn't create a `BrowserWindow` object in the renderer process.
|
||||
Instead, it created a `BrowserWindow` object in the main process and returned the
|
||||
corresponding remote object in the renderer process, namely the `win` object.
|
||||
|
||||
## Lifetime of remote objects
|
||||
|
||||
Electron makes sure that as long as the remote object in the renderer process
|
||||
lives (in other words, has not been garbage collected), the corresponding object
|
||||
in the main process would never be released. When the remote object has been
|
||||
garbage collected, the corresponding object in the main process would be
|
||||
dereferenced.
|
||||
|
||||
If the remote object is leaked in renderer process (e.g. stored in a map but never
|
||||
freed), the corresponding object in the main process would also be leaked,
|
||||
so you should be very careful not to leak remote objects.
|
||||
|
||||
Primary value types like strings and numbers, however, are sent by copy.
|
||||
|
||||
## Passing callbacks to the main process
|
||||
|
||||
Some APIs in the main process accept callbacks, and it would be tempting to
|
||||
pass callbacks when calling a remote function. The `remote` module does support
|
||||
doing this, but you should also be extremely careful with this.
|
||||
|
||||
First, in order to avoid deadlocks, the callbacks passed to the main process
|
||||
are called asynchronously, so you should not expect the main process to
|
||||
get the return value of the passed callbacks.
|
||||
|
||||
Second, the callbacks passed to the main process will not get released
|
||||
automatically after they are called. Instead, they will persistent until the
|
||||
main process garbage-collects them.
|
||||
|
||||
For example, the following code seems innocent at first glance. It installs a
|
||||
callback for the `close` event on a remote object:
|
||||
|
||||
```javascript
|
||||
var remote = require('remote');
|
||||
remote.getCurrentWindow().on('close', function() {
|
||||
// blabla...
|
||||
});
|
||||
```
|
||||
|
||||
The problem is that the callback would be stored in the main process until you
|
||||
explicitly uninstall it! So each time you reload your window, the callback would
|
||||
be installed again and previous callbacks would just leak. To make things
|
||||
worse, since the context of previously installed callbacks have been released,
|
||||
when the `close` event was emitted, exceptions would be raised in the main process.
|
||||
|
||||
Generally, unless you are clear what you are doing, you should always avoid
|
||||
passing callbacks to the main process.
|
||||
|
||||
## Remote buffer
|
||||
|
||||
An instance of node's `Buffer` is an object, so when you get a `Buffer` from
|
||||
the main process, what you get is indeed a remote object (let's call it remote
|
||||
buffer), and everything would just follow the rules of remote objects.
|
||||
|
||||
However you should remember that although a remote buffer behaves like the real
|
||||
`Buffer`, it's not a `Buffer` at all. If you pass a remote buffer to node APIs
|
||||
that accept a `Buffer`, you should assume the remote buffer would be treated
|
||||
like a normal object, instead of a `Buffer`.
|
||||
|
||||
For example, you can call `BrowserWindow.capturePage` in the renderer process, which
|
||||
returns a `Buffer` by calling the passed callback:
|
||||
|
||||
```javascript
|
||||
var remote = require('remote');
|
||||
var fs = require('fs');
|
||||
remote.getCurrentWindow().capturePage(function(image) {
|
||||
var buf = image.toPng();
|
||||
fs.writeFile('/tmp/screenshot.png', buf, function(err) {
|
||||
console.log(err);
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
But you may be surprised to find that the file written was corrupted. This is
|
||||
because when you called `fs.writeFile`, thinking that `buf` was a `Buffer` when
|
||||
in fact it was a remote buffer, and it was converted to string before it was
|
||||
written to the file. Since `buf` contained binary data and could not be represented
|
||||
by a UTF-8 encoded string, the written file was corrupted.
|
||||
|
||||
The work-around is to write the `buf` in the main process, where it is a real
|
||||
`Buffer`:
|
||||
|
||||
```javascript
|
||||
var remote = require('remote');
|
||||
remote.getCurrentWindow().capturePage(function(image) {
|
||||
var buf = image.toPng();
|
||||
remote.require('fs').writeFile('/tmp/screenshot.png', buf, function(err) {
|
||||
console.log(err);
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
The same thing could happen for all native types, but usually it would just
|
||||
throw a type error. The `Buffer` deserves your special attention because it
|
||||
might be converted to string, and APIs accepting `Buffer` usually accept string
|
||||
too, and data corruption could happen when it contains binary data.
|
||||
|
||||
## remote.require(module)
|
||||
|
||||
* `module` String
|
||||
|
||||
Returns the object returned by `require(module)` in the main process.
|
||||
|
||||
## remote.getCurrentWindow()
|
||||
|
||||
Returns the [BrowserWindow](browser-window-ko.md) object which this web page
|
||||
belongs to.
|
||||
|
||||
## remote.getCurrentWebContent()
|
||||
|
||||
Returns the WebContents object of this web page.
|
||||
|
||||
## remote.getGlobal(name)
|
||||
|
||||
* `name` String
|
||||
|
||||
Returns the global variable of `name` (e.g. `global[name]`) in the main
|
||||
process.
|
||||
|
||||
## remote.process
|
||||
|
||||
Returns the `process` object in the main process. This is the same as
|
||||
`remote.getGlobal('process')`, but gets cached.
|
||||
105
docs/api/screen-ko.md
Normal file
105
docs/api/screen-ko.md
Normal file
|
|
@ -0,0 +1,105 @@
|
|||
# screen
|
||||
|
||||
Gets various info about screen size, displays, cursor position, etc. You should
|
||||
not use this module until the `ready` event of `app` module gets emitted.
|
||||
|
||||
`screen` is an [EventEmitter](http://nodejs.org/api/events.html#events_class_events_eventemitter).
|
||||
|
||||
Make sure to note that in the renderer / DevTools, `window.screen` is a reserved DOM property, so writing `screen = require('screen')` won't work. In our examples below, we use `atomScreen` as the variable name instead.
|
||||
|
||||
An example of creating a window that fills the whole screen:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
var BrowserWindow = require('browser-window');
|
||||
|
||||
var mainWindow;
|
||||
|
||||
app.on('ready', function() {
|
||||
var atomScreen = require('screen');
|
||||
var size = atomScreen.getPrimaryDisplay().workAreaSize;
|
||||
mainWindow = new BrowserWindow({ width: size.width, height: size.height });
|
||||
});
|
||||
```
|
||||
|
||||
Another example of creating a window in the external display:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
var BrowserWindow = require('browser-window');
|
||||
|
||||
var mainWindow;
|
||||
|
||||
app.on('ready', function() {
|
||||
var atomScreen = require('screen');
|
||||
var displays = atomScreen.getAllDisplays();
|
||||
var externalDisplay = null;
|
||||
for (var i in displays) {
|
||||
if (displays[i].bounds.x > 0 || displays[i].bounds.y > 0) {
|
||||
externalDisplay = displays[i];
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
if (externalDisplay) {
|
||||
mainWindow = new BrowserWindow({
|
||||
x: externalDisplay.bounds.x + 50,
|
||||
y: externalDisplay.bounds.y + 50,
|
||||
});
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
## Event: display-added
|
||||
|
||||
* `event` Event
|
||||
* `newDisplay` Object
|
||||
|
||||
Emitted when `newDisplay` has been added.
|
||||
|
||||
## Event: display-removed
|
||||
|
||||
* `event` Event
|
||||
* `oldDisplay` Object
|
||||
|
||||
Emitted when `oldDisplay` has been removed.
|
||||
|
||||
## Event: display-metrics-changed
|
||||
|
||||
* `event` Event
|
||||
* `display` Object
|
||||
* `changedMetrics` Array
|
||||
|
||||
Emitted when a `display` has one or more metrics changed, `changedMetrics` is
|
||||
an array of strings that describe the changes. Possible changes are `bounds`,
|
||||
`workArea`, `scaleFactor` and `rotation`.
|
||||
|
||||
## screen.getCursorScreenPoint()
|
||||
|
||||
Returns the current absolute position of the mouse pointer.
|
||||
|
||||
## screen.getPrimaryDisplay()
|
||||
|
||||
Returns the primary display.
|
||||
|
||||
## screen.getAllDisplays()
|
||||
|
||||
Returns an array of displays that are currently available.
|
||||
|
||||
## screen.getDisplayNearestPoint(point)
|
||||
|
||||
* `point` Object
|
||||
* `x` Integer
|
||||
* `y` Integer
|
||||
|
||||
Returns the display nearest the specified point.
|
||||
|
||||
## screen.getDisplayMatching(rect)
|
||||
|
||||
* `rect` Object
|
||||
* `x` Integer
|
||||
* `y` Integer
|
||||
* `width` Integer
|
||||
* `height` Integer
|
||||
|
||||
Returns the display that most closely intersects the provided bounds.
|
||||
41
docs/api/shell-ko.md
Normal file
41
docs/api/shell-ko.md
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
# shell
|
||||
|
||||
`shell` 모듈은 데스크톱 환경 통합에 관련하여 제공되는 모듈입니다.
|
||||
|
||||
다음 예제는 기본 브라우저로 설정된 URL을 엽니다:
|
||||
|
||||
```javascript
|
||||
var shell = require('shell');
|
||||
shell.openExternal('https://github.com');
|
||||
```
|
||||
|
||||
## shell.showItemInFolder(fullPath)
|
||||
|
||||
* `fullPath` String
|
||||
|
||||
지정한 파일을 탐색기에서 보여줍니다. 가능한 경우 탐색기 내에서 파일을 선택합니다.
|
||||
|
||||
## shell.openItem(fullPath)
|
||||
|
||||
* `fullPath` String
|
||||
|
||||
지정한 파일을 데스크톱 기본 프로그램으로 엽니다.
|
||||
|
||||
## shell.openExternal(url)
|
||||
|
||||
* `url` String
|
||||
|
||||
제공된 외부 프로토콜 URL을 기반으로 데스크톱의 기본 프로그램으로 엽니다. (예를들어 mailto: URL은 해당 URL을 기본 메일 에이전트로 엽니다.)
|
||||
역자주: 폴더는 'file:\\\\C:\\'와 같이 지정하여 열 수 있습니다. (`\\`로 경로를 표현한 이유는 Escape 문자열을 참고하세요.)
|
||||
|
||||
## shell.moveItemToTrash(fullPath)
|
||||
|
||||
* `fullPath` String
|
||||
|
||||
Move the given file to trash and returns boolean status for the operation.
|
||||
|
||||
지정한 파일을 휴지통으로 이동합니다. 작업의 성공여부를 boolean 형으로 리턴합니다.
|
||||
|
||||
## shell.beep()
|
||||
|
||||
비프음을 재생합니다.
|
||||
39
docs/api/synopsis-ko.md
Normal file
39
docs/api/synopsis-ko.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
# 개요
|
||||
|
||||
Electron은 모든 [node.js's built-in 모듈](http://nodejs.org/api/)과 third-party node 모듈을 완벽하게 지원합니다. ([네이티브 모듈](../tutorial/using-native-node-modules-ko.md)을 포함해서)
|
||||
|
||||
Electron은 네이티브 데스크톱 어플리케이션을 개발 할 수 있도록 추가적인 built-in 모듈을 제공합니다.
|
||||
몇몇 모듈은 메인 프로세스에서만 사용할 수 있고 어떤 모듈은 랜더러 프로세스에서만 사용할 수 있습니다. 또한 두 프로세스 모두 사용할 수 있는 모듈도 있습니다.
|
||||
기본적인 규칙은 다음과 같습니다: GUI와 저 수준 시스템에 관련된 모듈은 오직 메인 프로세스에서만 사용할 수 있습니다.
|
||||
[메인 프로세스 vs. 랜더러 프로세스](../tutorial/quick-start-ko.md#메인 프로세스) 컨셉에 익숙해야 이 모듈들을 사용하기 쉬우므로 해당 문서를 정독하는 것을 권장합니다.
|
||||
|
||||
|
||||
메인 프로세스 스크립트는 일반 `node.js` 스크립트와 같습니다:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
var BrowserWindow = require('browser-window');
|
||||
|
||||
var window = null;
|
||||
|
||||
app.on('ready', function() {
|
||||
window = new BrowserWindow({width: 800, height: 600});
|
||||
window.loadUrl('https://github.com');
|
||||
});
|
||||
```
|
||||
|
||||
웹 페이지 역시 예외적인 node module을 사용할 수 있다는 점을 제외하면 일반 웹 페이지와 다를게 없습니다:
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<body>
|
||||
<script>
|
||||
var remote = require('remote');
|
||||
console.log(remote.require('app').getVersion());
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
어플리케이션을 실행하려면 [앱 실행하기](../tutorial/quick-start-ko.md#앱 실행하기) 문서를 참고하기 바랍니다.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Tray
|
||||
# Tray
|
||||
|
||||
`Tray`는 OS의 알림영역에 아이콘을 표시합니다. 보통 컨텍스트 메뉴(context menu)를 같이 사용합니다.
|
||||
|
||||
|
|
|
|||
61
docs/api/web-frame-ko.md
Normal file
61
docs/api/web-frame-ko.md
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
# web-frame
|
||||
|
||||
`web-frame` 모듈은 현재 웹 페이지의 랜더링 상태를 커스터마이즈 할 수 있도록 해줍니다.
|
||||
|
||||
다음 예제는 현재 페이지를 200% 줌 합니다.
|
||||
|
||||
```javascript
|
||||
var webFrame = require('web-frame');
|
||||
webFrame.setZoomFactor(2);
|
||||
```
|
||||
|
||||
## webFrame.setZoomFactor(factor)
|
||||
|
||||
* `factor` Number - Zoom 값
|
||||
|
||||
지정한 값으로 페이지를 줌 합니다. 줌 값은 퍼센트 / 100입니다. (예시: 300% = 3.0)
|
||||
|
||||
## webFrame.getZoomFactor()
|
||||
|
||||
현재 줌 값을 반환합니다.
|
||||
|
||||
## webFrame.setZoomLevel(level)
|
||||
|
||||
* `level` Number - Zoom level
|
||||
|
||||
지정한 레벨로 줌 레벨을 변경합니다. 0은 "기본 크기" 입니다.
|
||||
그리고 각각 레벨 값을 올리거나 내릴 때마다 20%씩 커지거나 작아지고 기본 크기의 50%부터 300%까지 조절 제한이 있습니다.
|
||||
|
||||
## webFrame.getZoomLevel()
|
||||
|
||||
현재 줌 레벨을 반환합니다.
|
||||
|
||||
## webFrame.setSpellCheckProvider(language, autoCorrectWord, provider)
|
||||
|
||||
* `language` String
|
||||
* `autoCorrectWord` Boolean
|
||||
* `provider` Object
|
||||
|
||||
Input field나 text area에 철자 검사(spell checking) 제공자를 설정합니다.
|
||||
|
||||
`provider`는 반드시 전달된 단어의 철자가 맞았는지 검사하는 `spellCheck` 메소드를 가지고 있어야 합니다.
|
||||
|
||||
[node-spellchecker][spellchecker]를 철자 검사 제공자로 사용하는 예제입니다:
|
||||
|
||||
```javascript
|
||||
require('web-frame').setSpellCheckProvider("en-US", true, {
|
||||
spellCheck: function(text) {
|
||||
return !(require('spellchecker').isMisspelled(text));
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
## webFrame.registerUrlSchemeAsSecure(scheme)
|
||||
|
||||
* `scheme` String
|
||||
|
||||
지정한 `scheme`을 보안 스킴으로 설정합니다.
|
||||
|
||||
보안 스킴은 혼합된 컨텐츠 경고를 발생시키지 않습니다. 예를 들어 `https` 와 `data`는 네트워크 공격자로부터 손상될 가능성이 없기 때문에 보안 스킴입니다.
|
||||
|
||||
[spellchecker]: https://github.com/atom/node-spellchecker
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# `<webview>` 태그
|
||||
# `<webview>` 태그
|
||||
|
||||
Use the `webview` tag to embed 'guest' content (such as web pages) in your
|
||||
Electron app. The guest content is contained within the `webview` container;
|
||||
|
|
@ -10,7 +10,7 @@ app; it doesn't have the same permissions as your web page and all interactions
|
|||
between your app and embedded content will be asynchronous. This keeps your app
|
||||
safe from the embedded content.
|
||||
|
||||
## 예제
|
||||
## 예제
|
||||
|
||||
To embed a web page in your app, add the `webview` tag to your app's embedder
|
||||
page (this is the app page that will display the guest content). In its simplest
|
||||
|
|
@ -45,7 +45,7 @@ and displays a "loading..." message during the load time:
|
|||
</script>
|
||||
```
|
||||
|
||||
## 태그 속성
|
||||
## 태그 속성
|
||||
|
||||
### src
|
||||
|
||||
|
|
@ -308,7 +308,7 @@ page can handle it by listening to the `channel` event of `ipc` module.
|
|||
See [WebContents.send](browser-window-ko.md#webcontentssendchannel-args) for
|
||||
examples.
|
||||
|
||||
## DOM 이벤트
|
||||
## DOM 이벤트
|
||||
|
||||
### did-finish-load
|
||||
|
||||
|
|
|
|||
57
docs/api/window-open-ko.md
Normal file
57
docs/api/window-open-ko.md
Normal file
|
|
@ -0,0 +1,57 @@
|
|||
# `window.open` 함수
|
||||
|
||||
`window.open` 함수가 호출되면 새 창에서 새로운 페이지를 불러옵니다.
|
||||
이 창은 `url`로 부터 만들어진 `BrowserWindow`의 새 인스턴스이며 본 객체 대신 페이지의 컨트롤이 제한된 프록시 객체를 반환합니다.
|
||||
|
||||
프록시 객체는 기존의 웹 페이지와 호환될 수 있도록 일부 제한된 표준 기능만 가지고 있습니다.
|
||||
창의 모든 컨트롤을 가지려면 `BrowserWindow`를 직접 생성하여 작업해야 합니다.
|
||||
|
||||
## window.open(url, [frameName[, features]])
|
||||
|
||||
* `url` String
|
||||
* `frameName` String
|
||||
* `features` String
|
||||
|
||||
`BrowserWindowProxy` 클래스의 객체를 반환하는 새로운 윈도우를 생성합니다.
|
||||
|
||||
## window.opener.postMessage(message, targetOrigin)
|
||||
|
||||
* `message` String
|
||||
* `targetOrigin` String
|
||||
|
||||
부모 윈도우에 메시지를 보냅니다. 특정한 origin을 지정할 수도 있으며 `*`를 지정하면 따로 origin 설정을 사용하지 않습니다.
|
||||
|
||||
## Class: BrowserWindowProxy
|
||||
|
||||
### BrowserWindowProxy.blur()
|
||||
|
||||
자식 윈도우의 포커스를 해제합니다.
|
||||
|
||||
### BrowserWindowProxy.close()
|
||||
|
||||
자식 윈도우를 강제로 닫습니다. unload 이벤트가 발생하지 않습니다.
|
||||
|
||||
Forcefully closes the child window without calling its unload event.
|
||||
|
||||
### BrowserWindowProxy.closed
|
||||
|
||||
자식 윈도우가 닫히면 true로 설정됩니다.
|
||||
|
||||
### BrowserWindowProxy.eval(code)
|
||||
|
||||
* `code` String
|
||||
|
||||
자식 윈도우에서 특정 스크립트를 실행합니다.
|
||||
|
||||
### BrowserWindowProxy.focus()
|
||||
|
||||
자식 윈도우에 포커스를 맞춥니다. (창을 맨 앞으로 가져옵니다)
|
||||
|
||||
### BrowserWindowProxy.postMessage(message, targetOrigin)
|
||||
|
||||
* `message` String
|
||||
* `targetOrigin` String
|
||||
|
||||
자식 윈도우에 메시지를 보냅니다. 특정한 origin을 지정할 수도 있으며 `*`를 지정하면 따로 origin 설정을 사용하지 않습니다.
|
||||
|
||||
참고로 자식 윈도우의 `window.opener` 객체에는 다른 속성 없이 이 함수 하나만 구현되어 있습니다.
|
||||
34
docs/development/atom-shell-vs-node-webkit-ko.md
Normal file
34
docs/development/atom-shell-vs-node-webkit-ko.md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
# NW.js와 기술적으로 다른점 (이전 node-webkit)
|
||||
|
||||
__알림: Electron은 이전까지 Atom Shell로 불려졌습니다.__
|
||||
|
||||
NW.js 처럼 Electron은 JavaScript와 HTML 그리고 Node 통합환경을 제공함으로써 웹 페이지에서 저수준 시스템에 접근할 수 있는 웹 기반 데스크탑 어플리케이션을 작성할 수 있도록 합니다.
|
||||
|
||||
하지만 Electron과 NW.js는 근본적인 개발흐름의 차이도 있습니다:
|
||||
|
||||
__1. 어플리케이션의 엔트리 포인트__
|
||||
|
||||
NW.js에선 어플리케이션의 엔트리 포인트로 웹 페이지를 사용합니다.
|
||||
`package.json`내의 main 필드에 메인 웹 페이지(index.html) 파일을 지정하면 어플리케이션의 메인 윈도우로 열리게 됩니다.
|
||||
|
||||
Electron에선 JavaScript를 엔트리 포인트로 사용합니다. URL을 직접 제공하는 대신 API를 사용하여 직접 브라우저 창과 HTML 파일을 로드할 수 있습니다.
|
||||
또한 윈도우의 종료시기를 결정하는 이벤트를 리스닝해야합니다.
|
||||
|
||||
Electron은 Node.js 런타임과 비슷하게 작동합니다. Electron의 API는 저수준이기에 브라우저 테스팅을 위해 [PhantomJS](http://phantomjs.org/)를 사용할 수도 있습니다.
|
||||
|
||||
__2. 빌드 시스템__
|
||||
|
||||
Electron은 Chromium의 모든것을 빌드하는 복잡성을 피하기 위해 [libchromiumcontent](https://github.com/brightray/libchromiumcontent)를 사용하여
|
||||
Chromium의 Content API에 접근합니다. libchromiumcontent은 단일 공유 라이브러리이고 Chromium Content 모듈과 종속성 라이브러리들을 포함합니다.
|
||||
유저는 Electron을 빌드 하기 위해 높은 사양의 빌드용 컴퓨터를 구비할 필요가 없습니다.
|
||||
|
||||
__3. Node 통합__
|
||||
|
||||
NW.js는 웹 페이지에서 require를 사용할 수 있도록 Chromium을 패치했습니다. 한편 Electron은 Chromium의 해킹을 방지하기 위해 libuv loop와 각 플랫폼의 메시지 루프에 통합하는 등의 다른 방법을 채택하였습니다.
|
||||
[`node_bindings`](../../atom/common/) 코드를 보면 이 부분이 어떻게 구현됬는지를 알 수 있습니다.
|
||||
|
||||
__4. 다중 컨텍스트__
|
||||
|
||||
만약 NW.js를 사용해본적이 있다면 Node context와 Web context의 개념을 잘 알고 있을겁니다. 이 개념은 NW.js가 구현된 방식에 따라 만들어졌습니다.
|
||||
|
||||
Node의 [다중 컨텍스트](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)를 사용할 경우 Electron은 웹 페이지에서 새로운 JavaScript 컨텍스트를 생성하지 않습니다.
|
||||
90
docs/development/build-instructions-linux-ko.md
Normal file
90
docs/development/build-instructions-linux-ko.md
Normal file
|
|
@ -0,0 +1,90 @@
|
|||
# 빌드 설명서 (Linux)
|
||||
|
||||
## 빌드전 요구사양
|
||||
|
||||
* Python 2.7.x. 몇몇 CentOS와 같은 배포판들은 아직도 Python 2.6.x 버전을 사용합니다. 그래서 `python -V`를 통해 버전을 확인해 줄 필요가 있습니다.
|
||||
* Node.js v0.12.x. Node를 설치하는 방법은 여러가지가 있습니다. 그중 하나는 [Node.js](http://nodejs.org) 사이트에서 소스코드를 받아 빌드하는 방법입니다.
|
||||
이렇게 하면 Node를 일반 유저로 홈 디렉터리에 설치할 수 있습니다. 또는 [NodeSource](https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories) 에서 받아올 수도 있습니다.
|
||||
자세한 내용은 [Node.js 설치 방법](https://github.com/joyent/node/wiki/Installation) 을 참고하세요.
|
||||
* Clang 3.4 또는 최신 버전
|
||||
* GTK+ 와 libnotify의 개발용 헤더
|
||||
|
||||
Ubuntu를 사용하고 있다면 다음 커맨드로 설치하면 합니다:
|
||||
|
||||
```bash
|
||||
$ sudo apt-get install build-essential clang libdbus-1-dev libgtk2.0-dev \
|
||||
libnotify-dev libgnome-keyring-dev libgconf2-dev \
|
||||
libasound2-dev libcap-dev libcups2-dev libxtst-dev \
|
||||
libxss1 gcc-multilib g++-multilib
|
||||
```
|
||||
|
||||
다른 배포판의 경우 yum과 같은 패키지 매니저를 통해 패키지를 설치 할 수 있습니다. 패키지의 이름은 대부분 비슷할 것입니다.
|
||||
또는 소스코드를 내려받아 직접 빌드하는 방법도 있습니다.
|
||||
|
||||
## 가상머신을 사용하여 빌드 하는 경우
|
||||
|
||||
만약 Electron을 가상머신으로 빌드 할 계획이라면 해당 가상머신의 스토리지를 최소 25GB 이상을 확보해 놓아야 합니다.
|
||||
|
||||
|
||||
## 코드 가져오기
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/atom/electron.git
|
||||
```
|
||||
|
||||
## 부트 스트랩
|
||||
|
||||
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
|
||||
스크립트가 정상적으로 작동하기 위해선 Python 2.7.x 버전이 필요합니다.
|
||||
아마 다운로드 작업이 상당히 많은 시간을 소요할 것입니다.
|
||||
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 `Makefile`은 생성되지 않습니다.
|
||||
|
||||
```bash
|
||||
$ cd electron
|
||||
$ ./script/bootstrap.py -v
|
||||
```
|
||||
|
||||
## 빌드 하기
|
||||
|
||||
`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py
|
||||
```
|
||||
|
||||
이 스크립트는 `out/R` 디렉터리에 크기가 매우 큰 Electron 실행 파일을 배치합니다. 파일 크기는 1.3GB를 초과합니다.
|
||||
이러한 문제가 발생하는 이유는 Release 타겟 바이너리가 디버그 심볼을 포함하기 때문입니다.
|
||||
파일 크기를 줄이려면 `create-dist.py` 스크립트를 실행하세요:
|
||||
|
||||
```bash
|
||||
$ ./script/create-dist.py
|
||||
```
|
||||
|
||||
이 스크립트는 매우 작은 배포판을 `dist` 디렉터리에 생성합니다.
|
||||
create-dist.py 스크립트를 실행한 이후 1.3GB를 초과하는 공간을 차지하는 out/R 폴더의 실행파일 바이너리는 삭제해도 됩니다.
|
||||
|
||||
`Debug` 타겟만 빌드 할 수도 있습니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
빌드가 모두 끝나면 `out/D` 디렉터리에서 `electron` 디버그 바이너리를 찾을 수 있습니다.
|
||||
|
||||
## 정리 하기
|
||||
|
||||
빌드 파일들을 정리합니다:
|
||||
|
||||
```bash
|
||||
$ ./script/clean.py
|
||||
```
|
||||
|
||||
## 문제 해결
|
||||
|
||||
개발 종속성 라이브러리들을 제대로 설치했는지 확인하세요.
|
||||
|
||||
## 테스트
|
||||
|
||||
```bash
|
||||
$ ./script/test.py
|
||||
```
|
||||
53
docs/development/build-instructions-mac-ko.md
Normal file
53
docs/development/build-instructions-mac-ko.md
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
# 빌드 설명서 (Mac)
|
||||
|
||||
## 빌드전 요구 사항
|
||||
|
||||
* OS X >= 10.8
|
||||
* [Xcode](https://developer.apple.com/technologies/tools/) >= 5.1
|
||||
* [node.js](http://nodejs.org) (external).
|
||||
|
||||
만약 Homebrew를 이용해 파이선을 설치했다면 다음 파이선 모듈도 같이 설치해야 합니다:
|
||||
|
||||
* pyobjc
|
||||
|
||||
## 코드 가져오기
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/atom/electron.git
|
||||
```
|
||||
|
||||
## 부트 스트랩
|
||||
|
||||
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
|
||||
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Xcode 프로젝트는 생성되지 않습니다.
|
||||
|
||||
```bash
|
||||
$ cd electron
|
||||
$ ./script/bootstrap.py -v
|
||||
```
|
||||
|
||||
## 빌드 하기
|
||||
|
||||
`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py
|
||||
```
|
||||
|
||||
`Debug` 타겟만 빌드 할 수도 있습니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
빌드가 모두 끝나면 `out/D` 디렉터리에서 `Electron.app` 실행 파일을 찾을 수 있습니다.
|
||||
|
||||
## 32비트 지원
|
||||
|
||||
Electron은 현재 OS X 64비트 빌드만 지원하고 있습니다. 그리고 앞으로도 OS X 32비트는 지원할 계획이 없습니다.
|
||||
|
||||
## 테스트
|
||||
|
||||
```bash
|
||||
$ ./script/test.py
|
||||
```
|
||||
117
docs/development/build-instructions-windows-ko.md
Normal file
117
docs/development/build-instructions-windows-ko.md
Normal file
|
|
@ -0,0 +1,117 @@
|
|||
# 빌드 설명서 (Windows)
|
||||
|
||||
## 빌드전 요구 사항
|
||||
|
||||
* Windows 7 / Server 2008 R2 또는 최신 버전
|
||||
* Visual Studio 2013 - [VS 2013 커뮤니티 에디션 무료 다운로드](http://www.visualstudio.com/products/visual-studio-community-vs)
|
||||
* [Python 2.7](http://www.python.org/download/releases/2.7/)
|
||||
* [Node.js](http://nodejs.org/download/)
|
||||
* [git](http://git-scm.com)
|
||||
|
||||
현재 Windows를 설치하지 않았다면 [modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads)에서
|
||||
사용기한이 정해져있는 무료 가상머신 버전의 Windows를 받아 Electron을 빌드할 수도 있습니다.
|
||||
|
||||
Electron은 전적으로 command-line 스크립트를 사용하여 빌드합니다. 그렇기에 Electron을 개발하는데 아무런 에디터나 사용할 수 있습니다.
|
||||
하지만 이 말은 Visual Studio를 개발을 위해 사용할 수 없다는 말이 됩니다. 나중에 Visual Studio를 이용한 빌드 방법도 제공할 예정입니다.
|
||||
|
||||
**참고:** Visual Studio가 빌드에 사용되지 않더라도 제공된 빌드 툴체인이 **필수적으로** 사용되므로 여전히 필요합니다.
|
||||
|
||||
## 코드 가져오기
|
||||
|
||||
```powershell
|
||||
git clone https://github.com/atom/electron.git
|
||||
```
|
||||
|
||||
## 부트 스트랩
|
||||
|
||||
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
|
||||
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Visual Studio 프로젝트는 생성되지 않습니다.
|
||||
|
||||
```powershell
|
||||
cd electron
|
||||
python script\bootstrap.py -v
|
||||
```
|
||||
|
||||
## 빌드 하기
|
||||
|
||||
`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
|
||||
|
||||
```powershell
|
||||
python script\build.py
|
||||
```
|
||||
|
||||
`Debug` 타겟만 빌드 할 수도 있습니다:
|
||||
|
||||
```powershell
|
||||
python script\build.py -c D
|
||||
```
|
||||
|
||||
빌드가 모두 끝나면 `out/D` 디렉터리에서 `atom.exe` 실행 파일을 찾을 수 있습니다.
|
||||
|
||||
## 64비트 빌드
|
||||
|
||||
64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때 `--target_arch=x64` 인자를 같이 넘겨주면 됩니다:
|
||||
|
||||
```powershell
|
||||
python script\bootstrap.py -v --target_arch=x64
|
||||
```
|
||||
|
||||
다른 빌드 단계도 정확하게 같습니다.
|
||||
|
||||
## 테스트
|
||||
|
||||
```powershell
|
||||
python script\test.py
|
||||
```
|
||||
|
||||
## 문제 해결
|
||||
|
||||
### Command xxxx not found
|
||||
|
||||
만약 `Command xxxx not found`와 같은 형식의 에러가 발생했다면 `VS2012 Command Prompt` 콘솔로 빌드 스크립트를 실행해볼 필요가 있습니다.
|
||||
|
||||
### Fatal internal compiler error: C1001
|
||||
|
||||
Visual Studio가 업데이트까지 완벽하게 설치된 최신버전인지 확인하세요.
|
||||
|
||||
### Assertion failed: ((handle))->activecnt >= 0
|
||||
|
||||
Cygwin에서 빌드 할 경우 `bootstrap.py` 스크립트가 다음의 에러와 함께 빌드에 실패할 수 있습니다:
|
||||
|
||||
```
|
||||
Assertion failed: ((handle))->activecnt >= 0, file src\win\pipe.c, line 1430
|
||||
|
||||
Traceback (most recent call last):
|
||||
File "script/bootstrap.py", line 87, in <module>
|
||||
sys.exit(main())
|
||||
File "script/bootstrap.py", line 22, in main
|
||||
update_node_modules('.')
|
||||
File "script/bootstrap.py", line 56, in update_node_modules
|
||||
execute([NPM, 'install'])
|
||||
File "/home/zcbenz/codes/raven/script/lib/util.py", line 118, in execute
|
||||
raise e
|
||||
subprocess.CalledProcessError: Command '['npm.cmd', 'install']' returned non-zero exit status 3
|
||||
```
|
||||
|
||||
이 버그는 Cygwin python과 Win32 node를 같이 사용할 경우 발생합니다.
|
||||
부트스트랩 스크립트에서 Win32 python을 사용함으로써 이 문제를 해결할 수 있습니다 (`C:\Python27` 디렉터리에 python이 설치되었다는 것을 가정하면):
|
||||
|
||||
```bash
|
||||
/cygdrive/c/Python27/python.exe script/bootstrap.py
|
||||
```
|
||||
|
||||
### LNK1181: cannot open input file 'kernel32.lib'
|
||||
|
||||
32bit node.js를 다시 설치하세요.
|
||||
|
||||
### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'
|
||||
|
||||
간단하게 해당 디렉터리를 생성하면 [문제가 해결될 겁니다](http://stackoverflow.com/a/25095327/102704):
|
||||
|
||||
```powershell
|
||||
mkdir ~\AppData\Roaming\npm
|
||||
```
|
||||
|
||||
### node-gyp is not recognized as an internal or external command
|
||||
|
||||
Git Bash로 빌드 했을 때 이러한 에러가 발생할 수 있습니다. 반드시 PowerShell이나 VS2012 Command Prompt에서 빌드를 진행해야 합니다.
|
||||
51
docs/development/build-system-overview-ko.md
Normal file
51
docs/development/build-system-overview-ko.md
Normal file
|
|
@ -0,0 +1,51 @@
|
|||
# 빌드 시스템 개요
|
||||
|
||||
Electron은 프로젝트 생성을 위해 `gyp`를 사용하며 `ninja`를 이용하여 빌드합니다.
|
||||
프로젝트 설정은 `.gyp` 와 `.gypi` 파일에서 볼 수 있습니다.
|
||||
|
||||
## gyp 파일들
|
||||
|
||||
Electron을 빌드 할 때 `gyp` 파일들은 다음과 같은 규칙을 따릅니다:
|
||||
|
||||
* `atom.gyp`는 Electron의 빌드 과정 자체를 정의합니다.
|
||||
* `common.gypi`는 Node가 Chromium과 함께 빌드될 수 있도록 조정한 빌드 설정입니다.
|
||||
* `vendor/brightray/brightray.gyp`는 `brightray`의 빌드 과정을 정의하고 Chromium과의 링킹에 대한 기본적인 설정을 포함합니다.
|
||||
* `vendor/brightray/brightray.gypi`는 빌드에 대한 일반적인 설정이 포함되어 있습니다.
|
||||
|
||||
## 구성요소 빌드
|
||||
|
||||
Chromium은 꽤나 큰 프로젝트입니다. 이 때문에 최종 링킹 작업은 상당한 시간이 소요될 수 있습니다.
|
||||
이러한 문제로 인해 개발 시 빌드 작업을 까다롭게 만듭니다. 이 문제를 해결하기 위해 Chromium은 "component build"를 도입했습니다.
|
||||
이는 각각의 컴포넌트를 각각 따로 분리하여 공유 라이브러리로 빌드 합니다. 이렇게 되면 링킹작업은 매우 빨라지지만 파일 크기와 성능이 느려집니다.
|
||||
|
||||
Electron도 상당히 비슷한 접근을 했습니다:
|
||||
`Debug`빌드 시 바이너리는 공유 라이브러리 버전의 Chromium 컴포넌트를 사용해서 링크 속도를 높이고
|
||||
`Release`빌드 시엔 정적 라이브러리 버전의 컴포넌트를 사용합니다.
|
||||
이렇게 각 빌드의 단점을 상호 보완하여 디버그 시 빌드 속도는 향상되고 배포판 빌드 시 공유 라이브러리의 단점은 제거했습니다.
|
||||
|
||||
## 부트스트랩 최소화
|
||||
|
||||
모든 사전 빌드 된 Chromium 바이너리들은 부트스트랩 스크립트가 실행될 때 다운로드됩니다.
|
||||
기본적으로 공유 라이브러리와 정적 라이브러리 모두 다운로드되며 최종 전체 파일 크기는 플랫폼에 따라 800MB에서 2GB까지 차지합니다.
|
||||
|
||||
만약 빠르게 Electron의 개발 또는 테스트만 하고 싶다면 `--dev` 플래그를 추가하여 공유 라이브러리만 다운로드할 수 있습니다:
|
||||
|
||||
```bash
|
||||
$ ./script/bootstrap.py --dev
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
## 프로젝트 생성 (two-phrase)
|
||||
|
||||
Electron은 `Release`와 `Debug` 빌드가 서로 다른 라이브러리 링크 방식을 사용합니다.
|
||||
그러나 `gyp`는 따로 빌드 설정을 분리하여 라이브러리 링크 방식을 정의하는 것을 지원하지 않습니다.
|
||||
|
||||
이러한 문제를 해결하기 위해 Electron은 링크 설정을 제어하는 `gyp` 변수 `libchromiumcontent_component`를 사용하고 `gyp`를 실행할 때 단 하나의 타겟만을 생성합니다.
|
||||
|
||||
## 타겟 이름
|
||||
|
||||
많은 프로젝트에서 타겟 이름을 `Release` 와 `Debug`를 사용하는데 반해 Electron은 `R`과 `D`를 대신 사용합니다.
|
||||
이유는 가끔 알 수 없는 이유(randomly)로 `Release` 와 `Debug` 중 하나만 빌드 설정에 정의되어 있을때 `gyp`가 크래시를 일으키는데
|
||||
전술한 바와 같이 Electron은 한번에 한개의 타겟만을 생성할 수 있기 때문입니다.
|
||||
|
||||
이 문제는 개발자에게만 영향을 미칩니다. 만약 단순히 Electron을 rebranding 하기 위해 빌드 한다면 이 문제에 신경 쓸 필요가 없습니다.
|
||||
|
|
@ -4,20 +4,19 @@
|
|||
|
||||
C++과 Python스크립트는 Chromium의 [코딩 스타일](http://www.chromium.org/developers/coding-style)을 따릅니다.
|
||||
파이선 스크립트 `script/cpplint.py`를 사용하여 모든 파일이 해당 코딩스타일에 맞게 코딩 되었는지 확인할 수 있습니다.
|
||||
|
||||
파이선의 버전은 2.7을 사용합니다.
|
||||
|
||||
## CoffeeScript
|
||||
|
||||
CoffeeScript의 경우 GitHub의 [스타일 가이드](https://github.com/styleguide/javascript)를 따릅니다, 동시에 다음 규칙도 따릅니다:
|
||||
CoffeeScript의 경우 GitHub의 [스타일 가이드](https://github.com/styleguide/javascript)를 따릅니다. 동시에 다음 규칙도 따릅니다:
|
||||
|
||||
* Google의 코딩 스타일에도 맞추기 위해, 파일의 끝에는 **절대** 개행을 삽입해선 안됩니다.
|
||||
* Google의 코딩 스타일에도 맞추기 위해 파일의 끝에는 **절대** 개행을 삽입해선 안됩니다.
|
||||
* 파일 이름의 공백은 `_`대신에 `-`을 사용하여야 합니다. 예를 들어 `file_name.coffee`를
|
||||
`file-name.coffee`로 고쳐야합니다, 왜냐하면 [github/atom](https://github.com/github/atom) 에서 사용되는 모듈의 이름은
|
||||
보통 `module-name`형식이기 때문입니다, 이 규칙은 '.coffee' 파일에만 적용됩니다.
|
||||
`file-name.coffee`로 고쳐야합니다. 왜냐하면 [github/atom](https://github.com/github/atom) 에서 사용되는 모듈의 이름은
|
||||
보통 `module-name`형식이기 때문입니다. 이 규칙은 '.coffee' 파일에만 적용됩니다.
|
||||
|
||||
## API 이름
|
||||
|
||||
새로운 API를 만들 땐, getter, setter스타일 대신 jQuery의 one-function스타일을 사용해야 합니다. 예를 들어,
|
||||
새로운 API를 만들 땐 getter, setter스타일 대신 jQuery의 one-function스타일을 사용해야 합니다. 예를 들어
|
||||
`.getText()`와 `.setText(text)`대신에 `.text([text])`형식으로 설계하면 됩니다.
|
||||
포럼에 이 문제에 대한 [논의](https://github.com/atom/electron/issues/46)가 있습니다.
|
||||
|
|
|
|||
44
docs/development/setting-up-symbol-server-ko.md
Normal file
44
docs/development/setting-up-symbol-server-ko.md
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
# 디버거에서 디버그 심볼 서버 설정
|
||||
|
||||
디버그 심볼은 디버깅 세션을 더 좋게 개선해 줍니다. 디버그 심볼은 실행 파일과 동적 링크 라이브러리에서 함수에 대한 정보를 담고 있으며 명료한 함수 호출 스텍 정보를 제공합니다.
|
||||
심볼 서버는 유저가 크기가 큰 디버깅용 파일을 필수적으로 다운로드 받지 않고도 디버거가 알맞은 심볼, 바이너리 그리고 소스를 자동적으로 로드할 수 있도록 해줍니다.
|
||||
서버 사용법은 [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가 원하는 경로로 수정할 수 있습니다):
|
||||
|
||||
```
|
||||
SRV*c:\code\symbols\*http://54.249.141.255:8086/atom-shell/symbols
|
||||
```
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
## Visual Studio에서 심볼 서버 사용하기
|
||||
|
||||
<img src='http://mdn.mozillademos.org/files/733/symbol-server-vc8express-menu.jpg'>
|
||||
<img src='http://mdn.mozillademos.org/files/2497/2005_options.gif'>
|
||||
|
||||
## 문제 해결: Symbols will not load
|
||||
|
||||
Windbg에서 다음의 커맨드를 입력하여 왜 심볼이 로드되지 않았는지에 대한 오류 내역을 출력합니다:
|
||||
|
||||
```
|
||||
> !sym noisy
|
||||
> .reload /f chromiumcontent.dll
|
||||
```
|
||||
48
docs/development/source-code-directory-structure-ko.md
Normal file
48
docs/development/source-code-directory-structure-ko.md
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
# 소스 코드 디렉터리 구조
|
||||
|
||||
## 개요
|
||||
|
||||
Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 우리는 Chromium의 분리 규칙(separation conventions)을 주로 따르고 있습니다.
|
||||
|
||||
이미 [Chromium의 멀티 프로세스 아키텍쳐](http://dev.chromium.org/developers/design-documents/multi-process-architecture)에 익숙해져 있다면 소스 코드를 이해하기 쉬울 것입니다.
|
||||
|
||||
## 소스 코드 구조
|
||||
|
||||
* **atom** - Electron의 소스코드.
|
||||
* **app** - 시스템 엔트리 코드.
|
||||
* **browser** - 주 윈도우를 포함한 프론트엔드, UI, 그리고 메인 프로세스에 관련된 것들. 주 랜더러와 웹 페이지 관리관련 코드.
|
||||
* **lib** - 메인 프로세스 초기화 코드의 자바스크립트 파트.
|
||||
* **ui** - 크로스 플랫폼에 대응하는 UI 구현.
|
||||
* **cocoa** - 코코아 특정 소스 코드.
|
||||
* **gtk** - GTK+ 특정 소스 코드.
|
||||
* **win** - Windows GUI 특정 소스 코드.
|
||||
* **default_app** - 어플리케이션이 제공되지 않으면 기본적으로 사용될 페이지.
|
||||
* **api** - 메인 프로세스 API들의 구현.
|
||||
* **lib** - API 구현의 자바스크립트 파트.
|
||||
* **net** - 네트워크 관련 코드.
|
||||
* **mac** - Mac 특정 Objective-C 소스 코드.
|
||||
* **resources** - 아이콘들, 플랫폼 종속성 파일들, 기타 등등.
|
||||
* **renderer** - 렌더러 프로세스에서 작동하는 코드들.
|
||||
* **lib** - 렌더러 프로세스 초기화 코드의 자바스크립트 파트.
|
||||
* **api** - 렌더러 프로세스 API들의 구현.
|
||||
* **lib** - API 구현의 자바스크립트 파트.
|
||||
* **common** - 메인 프로세스와 렌더러 프로세스에서 공유하는 코드. 유틸리티 함수와 node 메시지 루프를 Chromium의 메시지 루프에 통합시킨 코드가 포함.
|
||||
* **lib** - 공통 자바스크립트 초기화 코드.
|
||||
* **api** - 공통 API들의 구현, Electron의 빌트인 모듈 기초 코드들.
|
||||
* **lib** - API 구현의 자바스크립트 파트.
|
||||
* **chromium_src** - 복사된 Chromium 소스 코드.
|
||||
* **docs** - 참조 문서.
|
||||
* **spec** - 자동화된 테스트.
|
||||
* **atom.gyp** - Electron의 빌드 규칙.
|
||||
* **common.gypi** - 컴파일러 설정 및 `node` 와 `breakpad` 등의 구성요소를 위한 빌드 규칙.
|
||||
|
||||
## 그외 디렉터리 구조
|
||||
|
||||
* **script** - 개발목적으로 사용되는 빌드, 패키징, 테스트, 기타등을 실행하는 스크립트.
|
||||
* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트 `script`와는 다르게 유저로부터 직접 실행되지 않는 스크립트들을 이곳에 넣습니다.
|
||||
* **vendor** - 소스코드의 서드파티 종속성 코드 소스 코드 디렉터리가 겹쳐 혼란을 일으킬 수 있기 때문에
|
||||
우리는 `third_party`와 같은 Chromium 소스 코드 디렉터리에서 사용된 폴더 이름을 사용하지 않았습니다.
|
||||
* **node_modules** - 빌드에 사용되는 node 서드파티 모듈.
|
||||
* **out** - `ninja`의 임시 출력 디렉터리.
|
||||
* **dist** - 배포용 바이너리를 빌드할 때 사용하는 `script/create-dist.py` 스크립트로부터 만들어지는 임시 디렉터리.
|
||||
* **external_binaries** - `gyp`를 통한 빌드가 지원하지 않아 따로 다운로드된 서드파티 프레임워크 바이너리들.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# 어플리케이션 배포
|
||||
# 어플리케이션 배포
|
||||
|
||||
Electron 어플리케이션을 배포할 때는 어플리케이션 폴더의 이름을 `app`으로 지정한 후 Electron 실행파일의 리소스 디렉터리에 집어넣어야합니다.
|
||||
리소스 디렉터리는 OS X에선 `Electron.app/Contents/Resources/` Windows와 Linux에선 `resources/` 입니다.
|
||||
|
|
@ -23,12 +23,12 @@ electron/resources/app
|
|||
└── index.html
|
||||
```
|
||||
|
||||
그리고 `Electron.app`을 실행하면 (Linux에선 `electron` Windows에선 `electron.exe`입니다), Electron은 해당 앱을 실행시킵니다.
|
||||
그리고 `Electron.app`을 실행하면(Linux에선 `electron` Windows에선 `electron.exe`입니다) Electron은 해당 앱을 실행시킵니다.
|
||||
최종 사용자에게는 이 `electron` 폴더(Electron.app)를 배포하면 됩니다.
|
||||
|
||||
## asar로 앱 패키징 하기
|
||||
|
||||
소스파일 전체를 복사해서 배포하는 것과는 별개로, [asar](https://github.com/atom/asar) 아카이브를 통해
|
||||
소스파일 전체를 복사해서 배포하는 것과는 별개로 [asar](https://github.com/atom/asar) 아카이브를 통해
|
||||
어플리케이션의 소스코드가 사용자에게 노출되는 것을 방지할 수 있습니다.
|
||||
|
||||
`asar` 아카이브를 사용할 땐 단순히 `app` 폴더 대신에 어플리케이션을 패키징한 `app.asar` 파일로 대체하면됩니다.
|
||||
|
|
@ -48,11 +48,11 @@ electron/resources/
|
|||
└── app.asar
|
||||
```
|
||||
|
||||
자세한 내용은 [어플리케이션 패키징](application-packaging.md)에서 찾아볼 수 있습니다.
|
||||
자세한 내용은 [어플리케이션 패키징](application-packaging-ko.md)에서 찾아볼 수 있습니다.
|
||||
|
||||
## 다운로드한 바이너리의 리소스를 앱에 맞게 수정하기
|
||||
|
||||
어플리케이션을 Electron에 번들링한 후, 해당 어플리케이션에 맞게 리브랜딩 할 수 있습니다.
|
||||
어플리케이션을 Electron에 번들링한 후 해당 어플리케이션에 맞게 리브랜딩 할 수 있습니다.
|
||||
|
||||
### Windows
|
||||
|
||||
|
|
@ -97,11 +97,11 @@ MyApp.app/Contents
|
|||
### Linux
|
||||
|
||||
실행파일 `electron`의 이름을 원하는 대로 바꿀 수 있습니다.
|
||||
리눅스 어플리케이션의 아이콘은 [.desktop file](https://developer.gnome.org/integration-guide/stable/desktop-files.html.en)을 사용하여 지정할 수 있습니다.
|
||||
리눅스 어플리케이션의 아이콘은 [.desktop](https://developer.gnome.org/integration-guide/stable/desktop-files.html.en) 파일을 사용하여 지정할 수 있습니다.
|
||||
|
||||
### 역자주-자동화
|
||||
|
||||
일일이 Electron의 리소스를 수정하는 것은 상당히 귀찮고 복잡합니다.
|
||||
배포시에 Electron의 리소스를 일일이 수정하는 것은 매우 귀찮고 복잡합니다.
|
||||
하지만 이 작업을 자동화 시킬 수 있는 몇가지 방법이 있습니다:
|
||||
|
||||
* [electron-builder](https://github.com/loopline-systems/electron-builder)
|
||||
|
|
@ -135,4 +135,4 @@ $ script/build.py -c Release -t myapp
|
|||
Electron의 소스코드를 수정하고 다시 빌드하는 작업은 상당히 복잡합니다.
|
||||
이를 해결하기 위해 [grunt-build-atom-shell](https://github.com/paulcbetts/grunt-build-atom-shell)를 사용하여 빌드를 자동화 시킬 수 있습니다.
|
||||
|
||||
이 툴을 사용하면 자동적으로 `.gyp`파일을 수정하고 다시 빌드합니다. 그리고 어플리케이션의 네이티브 Node 모듈 또한 새로운 실행파일 이름으로 매치 시킵니다.
|
||||
이 툴을 사용하면 자동으로 `.gyp`파일을 수정하고 다시 빌드합니다. 그리고 어플리케이션의 네이티브 Node 모듈 또한 새로운 실행파일 이름으로 매치 시킵니다.
|
||||
|
|
|
|||
|
|
@ -1,37 +1,37 @@
|
|||
# 어플리케이션 패키징
|
||||
# 어플리케이션 패키징
|
||||
|
||||
어플리케이션의 리소스와 소스코드를 유저로부터 보호하기 위해, 약간의 구조 변경으로 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
|
||||
어플리케이션의 리소스와 소스코드를 유저로부터 보호하기 위해 약간의 구조 변경으로 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
|
||||
|
||||
## `asar` 아카이브 생성
|
||||
## `asar` 아카이브 생성
|
||||
|
||||
[asar][asar]아카이브는 tar과 비슷한 포맷으로 모든 리소스를 하나의 파일로 만듭니다.
|
||||
그리고 Electron은 압축해제 없이 임의로 모든 파일을 읽어들일 수 있습니다.
|
||||
[asar][asar]아카이브는 tar과 비슷한 포맷으로 모든 리소스를 하나의 파일로 만듭니다.
|
||||
그리고 Electron은 압축해제 없이 임의로 모든 파일을 읽어들일 수 있습니다.
|
||||
|
||||
다음 몇가지 단계를 통해 어플리케이션을 `asar` 아카이브로 압축할 수 있습니다:
|
||||
다음 몇가지 단계를 통해 어플리케이션을 `asar` 아카이브로 압축할 수 있습니다:
|
||||
|
||||
### 1. asar 유틸리티 설치
|
||||
### 1. asar 유틸리티 설치
|
||||
|
||||
```bash
|
||||
$ npm install -g asar
|
||||
```
|
||||
|
||||
### 2. `asar pack` 커맨드로 앱 패키징
|
||||
### 2. `asar pack` 커맨드로 앱 패키징
|
||||
|
||||
```bash
|
||||
$ asar pack your-app app.asar
|
||||
```
|
||||
|
||||
## `asar` 아카이브 사용하기
|
||||
## `asar` 아카이브 사용하기
|
||||
|
||||
Electron은 두가지의 API를 가지고 있습니다: Node.js로 부터 제공된 Node API, Chromium으로부터 제공된 Web API.
|
||||
두 API 모두 `asar`에서 읽어들일 수 있도록 지원합니다.
|
||||
Electron은 Node.js로 부터 제공된 Node API와 Chromium으로부터 제공된 Web API 두가지의 API를 가지고 있습니다.
|
||||
두 API 모두 `asar`에서 읽어들일 수 있도록 지원합니다.
|
||||
|
||||
### Node API
|
||||
|
||||
`fs.readFile` 와 `require` 같은 Node API들을 지원하기 위해 Electron에선 `asar` 아카이브가 가상의 디렉터리 구조를 가지도록
|
||||
패치했습니다. 그래서 아카이브 내부에서 리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다.
|
||||
`fs.readFile` 와 `require` 같은 Node API들을 지원하기 위해 Electron에선 `asar` 아카이브가 가상의 디렉터리 구조를 가지도록
|
||||
패치했습니다. 그래서 아카이브 내부에서 리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다.
|
||||
|
||||
예를들어, `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면:
|
||||
예를들어 `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면:
|
||||
|
||||
```bash
|
||||
$ asar list /path/to/example.asar
|
||||
|
|
@ -43,27 +43,27 @@ $ asar list /path/to/example.asar
|
|||
/static/jquery.min.js
|
||||
```
|
||||
|
||||
`asar` 아카이브에선 다음과 같이 파일을 읽을 수 있습니다:
|
||||
`asar` 아카이브에선 다음과 같이 파일을 읽을 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var fs = require('fs');
|
||||
fs.readFileSync('/path/to/example.asar/file.txt');
|
||||
```
|
||||
|
||||
아카이브 내의 루트 디렉터리를 리스팅합니다:
|
||||
아카이브 내의 루트 디렉터리를 리스팅합니다:
|
||||
|
||||
```javascript
|
||||
var fs = require('fs');
|
||||
fs.readdirSync('/path/to/example.asar');
|
||||
```
|
||||
|
||||
아카이브 안의 모듈 사용하기:
|
||||
아카이브 안의 모듈 사용하기:
|
||||
|
||||
```javascript
|
||||
require('/path/to/example.asar/dir/module.js');
|
||||
```
|
||||
|
||||
`BrowserWindow` 클래스를 이용해 원하는 웹 페이지도 표시할 수 있습니다:
|
||||
`BrowserWindow` 클래스를 이용해 원하는 웹 페이지도 표시할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var BrowserWindow = require('browser-window');
|
||||
|
|
@ -73,10 +73,10 @@ win.loadUrl('file:///path/to/example.asar/static/index.html');
|
|||
|
||||
### Web API
|
||||
|
||||
웹 페이지 내에선, 아카이브 내의 파일을 `file:` 프로토콜을 사용하여 요청할 수 있습니다.
|
||||
이 또한 Node API와 같이 가상 디렉터리 구조를 가집니다.
|
||||
웹 페이지 내에선 아카이브 내의 파일을 `file:` 프로토콜을 사용하여 요청할 수 있습니다.
|
||||
이 또한 Node API와 같이 가상 디렉터리 구조를 가집니다.
|
||||
|
||||
예를들어, jQuery의 `$.get`을 사용하여 파일을 가져올 수 있습니다:
|
||||
예를들어 jQuery의 `$.get`을 사용하여 파일을 가져올 수 있습니다:
|
||||
|
||||
```html
|
||||
<script>
|
||||
|
|
@ -87,67 +87,63 @@ $.get('file:///path/to/example.asar/file.txt', function(data) {
|
|||
</script>
|
||||
```
|
||||
|
||||
### `asar` 아카이브를 일반 파일로 취급하기
|
||||
### `asar` 아카이브를 일반 파일로 취급하기
|
||||
|
||||
`asar` 아카이브의 체크섬(checksum)등을 검사하기 위해선, `asar` 아카이브를 파일 그대로 읽어들여야 할 필요가 있습니다.
|
||||
이 작업을 하기 위해 `original-fs`라고 하는 빌트인 모듈을 `fs` 모듈 대신에 사용할 수 있습니다.
|
||||
이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를 읽어들입니다:
|
||||
`asar` 아카이브의 체크섬(checksum)등을 검사하기 위해선 `asar` 아카이브를 파일 그대로 읽어들여야 할 필요가 있습니다.
|
||||
이 작업을 하기 위해 `original-fs`라고 하는 빌트인 모듈을 `fs` 모듈 대신에 사용할 수 있습니다.
|
||||
이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를 읽어들입니다:
|
||||
|
||||
```javascript
|
||||
var originalFs = require('original-fs');
|
||||
originalFs.readFileSync('/path/to/example.asar');
|
||||
```
|
||||
|
||||
## Node API의 한계
|
||||
## Node API의 한계
|
||||
|
||||
`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만, 여전히 저수준(low-level) Node API 때문에 한계가 있습니다.
|
||||
`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만 여전히 저수준(low-level nature) Node API 때문에 한계가 있습니다.
|
||||
|
||||
Even though we tried hard to make `asar` archives in the Node API work like
|
||||
directories as much as possible, there are still limitations due to the
|
||||
low-level nature of the Node API.
|
||||
### 아카이브는 읽기 전용입니다
|
||||
|
||||
### 아카이브는 읽기 전용입니다
|
||||
아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만 `asar` 아카이브에선 작동하지 않습니다.
|
||||
|
||||
아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만, `asar` 아카이브에선 작동하지 않습니다.
|
||||
### 아카이브 안의 디렉터리를 작업 경로로 설정하면 안됩니다
|
||||
|
||||
### 아카이브 안의 디렉터리를 작업 경로로 설정하면 안됩니다
|
||||
`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만 그것은 실제 파일시스템의 디렉터리가 아닌 가상의 디렉터리입니다.
|
||||
그런 이유로 몇몇 API에서 지원하는 `cwd` 옵션을 `asar` 아카이브 안의 디렉터리 경로로 지정하면 나중에 문제가 발생할 수 있습니다.
|
||||
|
||||
`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만, 그것은 실제 파일시스템의 디렉터리가 아닌 가상의 디렉터리입니다.
|
||||
그런 이유로 몇몇 API에서 지원하는 `cwd` 옵션을 `asar` 아카이브 안의 디렉터리 경로로 지정하면 나중에 문제가 발생할 수 있습니다.
|
||||
### 특정 API로 인한 예외적인 압축 해제
|
||||
|
||||
### 특정 API로 인한 예외적인 압축 해제
|
||||
많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를 가져올 수 있으나
|
||||
몇몇 API는 시스템의 실제 파일의 경로를 기반으로 작동하므로 이 API들을 사용할 땐 Electron은
|
||||
이 API가 원할하게 작동할 수 있도록 하기 위해 임시경로에 해당 파일들의 압축을 해제합니다. 이 작업은 약간의 오버헤드를 불러 일으킬 수 있습니다.
|
||||
|
||||
많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를 가져올 수 있으나,
|
||||
몇몇 API는 시스템의 실제 파일의 경로를 기반으로 작동하므로 이 API들을 사용할 땐 Electron은
|
||||
이 API가 원할하게 작동할 수 있도록 하기 위해 임시경로에 해당 파일들의 압축을 해제합니다. 이 작업은 약간의 오버헤드를 불러 일으킬 수 있습니다.
|
||||
|
||||
해당하는 API 함수는 다음과 같습니다:
|
||||
해당하는 API 함수는 다음과 같습니다:
|
||||
|
||||
* `child_process.execFile`
|
||||
* `fs.open`
|
||||
* `fs.openSync`
|
||||
* `process.dlopen` - Used by `require` on native modules
|
||||
|
||||
### `fs.stat`의 잘못된 스테이터스
|
||||
### `fs.stat`의 잘못된 스테이터스 정보
|
||||
|
||||
`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 가상의 예측된 정보를 가집니다.
|
||||
왜냐하면 아카이브의 디렉터리 경로는 실제 파일시스템에 존재하지 않기 때문입니다.
|
||||
그러한 이유로 파일 크기와 파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다.
|
||||
`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 예측된 디렉터리 피일 정보를 가집니다.
|
||||
왜냐하면 아카이브의 디렉터리 경로는 실제 파일시스템에 존재하지 않기 때문입니다.
|
||||
그러한 이유로 파일 크기와 파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다.
|
||||
|
||||
## Adding unpacked files in `asar` archive
|
||||
## `asar` 아카이브에 미리 압축 해제된 파일 추가하기
|
||||
|
||||
전술한 바와 같이, 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다.
|
||||
따로 성능문제가 발생할 수 있습니다. 그리고 백신 소프트웨어의 잘못된 오진을 일으킬 수도 있습니다.
|
||||
전술한 바와 같이 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다.
|
||||
따로 성능문제가 발생할 수 있습니다. 그리고 백신 소프트웨어의 잘못된 오진을 일으킬 수도 있습니다.
|
||||
|
||||
이 문제를 해결하려면, `--unpack` 옵션을 활용하여 파일을 압축이 풀려진 상태로 유지해야 합니다.
|
||||
다음의 예제는 node 네이티브 모듈의 공유 라이브러리를 unpack 상태로 유지합니다:
|
||||
이 문제를 해결하려면 `--unpack` 옵션을 활용하여 파일을 압축이 풀려진 상태로 유지해야 합니다.
|
||||
다음의 예제는 node 네이티브 모듈의 공유 라이브러리를 unpack 상태로 유지합니다:
|
||||
|
||||
```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,7 @@
|
|||
# 메인 프로세스 디버깅하기
|
||||
|
||||
브라우저 창의 개발자 콘솔은 랜더러 프로세스의 스크립트만 디버깅이 가능합니다. (다시말해 웹 페이지)
|
||||
메인 프로세스의 디버깅 방법을 제공하기 위해, Electron은 `--debug` 과 `--debug-brk` 스위치들을 제공합니다.
|
||||
메인 프로세스의 디버깅 방법을 제공하기 위해 Electron은 `--debug` 과 `--debug-brk` 스위치들을 제공합니다.
|
||||
|
||||
## 커맨드 라인 스위치(command line switches)
|
||||
|
||||
|
|
@ -15,7 +15,7 @@
|
|||
|
||||
## node-inspector로 디버깅 하기
|
||||
|
||||
__주의:__ Electron은 node v0.11.13 버전을 사용합니다, node-inspector는 현재 아주 잘 작동하지 않습니다.
|
||||
__주의:__ Electron은 node v0.11.13 버전을 사용합니다. node-inspector는 현재 아주 잘 작동하지 않습니다.
|
||||
그리고 메인 프로세스의 `process`를 node-inspector 콘솔 내에서 검사할 경우 크래시가 발생할 수 있습니다.
|
||||
|
||||
### 1. [node-inspector][node-inspector] 서버 시작
|
||||
|
|
|
|||
|
|
@ -1,36 +1,30 @@
|
|||
# 데스크톱 환경 통합
|
||||
# 데스크톱 환경 통합
|
||||
|
||||
Different operating systems provide different features on integrating desktop
|
||||
applications into their desktop environments. For example, on Windows
|
||||
applications can put shortcuts in the JumpList of task bar, and on Mac
|
||||
applications can put a custom menu in the dock menu.
|
||||
어플리케이션을 배포할 서로 다른 운영체제 시스템의 환경과 기능에 맞춰 사용 환경을 통합할 수 있습니다.
|
||||
예를 들어 Windows에선 태스크바의 JumpList에 바로가기를 추가할 수 있고 Mac(OS X)에선 dock menu에 커스텀 메뉴를 추가할 수 있습니다.
|
||||
|
||||
This guide explains how to integrate your application into those desktop
|
||||
environments with Electron APIs.
|
||||
이 가이드는 Electron API를 이용하여 각 운영체제 시스템의 기능을 활용하는 방법을 설명합니다.
|
||||
|
||||
## 최근 사용한 문서 (Windows & OS X)
|
||||
|
||||
Windows and OS X provide easy access to a list of recent documents opened by
|
||||
the application via JumpList and dock menu.
|
||||
Windows와 OS X는 dock menu나 JumpList등을 통하여 최근 문서 리스트에 쉽게 접근할 수 있습니다.
|
||||
|
||||
__JumpList:__
|
||||
|
||||
|
||||
|
||||
|
||||
__Application dock menu:__
|
||||
__어플리케이션 dock menu:__
|
||||
|
||||
<img src="https://cloud.githubusercontent.com/assets/639601/5069610/2aa80758-6e97-11e4-8cfb-c1a414a10774.png" height="353" width="428" >
|
||||
|
||||
To add a file to recent documents, you can use
|
||||
[app.addRecentDocument][addrecentdocument] API:
|
||||
파일을 최근 문서에 추가하려면 [app.addRecentDocument][addrecentdocument] API를 사용할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
app.addRecentDocument('/Users/USERNAME/Desktop/work.type');
|
||||
```
|
||||
|
||||
And you can use [app.clearRecentDocuments](clearrecentdocuments) API to empty
|
||||
the recent documents list:
|
||||
그리고 [app.clearRecentDocuments](clearrecentdocuments) API로 최근 문서 리스트를 비울 수 있습니다:
|
||||
|
||||
```javascript
|
||||
app.clearRecentDocuments();
|
||||
|
|
@ -38,30 +32,26 @@ app.clearRecentDocuments();
|
|||
|
||||
### Windows에서 주의할 점
|
||||
|
||||
In order to be able to use this feature on Windows, your application has to be
|
||||
registered as a handler of the file type of the document, otherwise the file
|
||||
won't appear in JumpList even after you have added it. You can find everything
|
||||
on registering your application in [Application Registration][app-registration].
|
||||
이 기능을 Windows에서 사용할 땐 운영체제 시스템에 어플리케이션에서 사용하는 파일 확장자가 등록되어 있어야 합니다.
|
||||
그렇지 않은 경우 파일을 JumpList에 추가해도 추가되지 않습니다.
|
||||
어플리케이션 등록에 관련된 API의 모든 내용은 [Application Registration][app-registration]에서 찾아볼 수 있습니다.
|
||||
|
||||
When a user clicks a file from JumpList, a new instance of your application will
|
||||
be started with the path of the file added as a command line argument.
|
||||
유저가 JumpList에서 파일을 클릭할 경우 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어 새로운 인스턴스의 어플리케이션이 실행됩니다.
|
||||
|
||||
### OS X에서 주의할 점
|
||||
|
||||
When a file is requested from the recent documents menu, the `open-file` event
|
||||
of `app` module would be emitted for it.
|
||||
파일이 최근 문서 메뉴에서 요청될 경우 `app` 모듈의 `open-file` 이벤트가 호출됩니다.
|
||||
|
||||
## 커스텀 독 메뉴 (OS X)
|
||||
|
||||
OS X enables developers to specify a custom menu for the dock, which usually
|
||||
contains some shortcuts for commonly used features of your application:
|
||||
OS X는 개발자가 dock에 커스텀 메뉴를 만들 수 있도록 허용하고 있습니다.
|
||||
보통 어플리케이션의 특정 기능 바로가기를 만들 때 사용합니다:
|
||||
|
||||
__Dock menu of Terminal.app:__
|
||||
__Terminal.app의 dock menu:__
|
||||
|
||||
<img src="https://cloud.githubusercontent.com/assets/639601/5069962/6032658a-6e9c-11e4-9953-aa84006bdfff.png" height="354" width="341" >
|
||||
|
||||
To set your custom dock menu, you can use the `app.dock.setMenu` API, which is
|
||||
only available on OS X:
|
||||
커스텀 dock menu를 설정하려면 `app.dock.setMenu` API를 사용하면 됩니다. OS X에서만 사용 가능합니다:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
|
|
@ -79,36 +69,29 @@ app.dock.setMenu(dockMenu);
|
|||
|
||||
## 사용자 작업 (Windows)
|
||||
|
||||
On Windows you can specify custom actions in the `Tasks` category of JumpList,
|
||||
as quoted from MSDN:
|
||||
Windows에선 JumpList의 `Tasks` 카테고리에 원하는 작업을 설정할 수 있습니다.
|
||||
MSDN에선 해당 기능을 다음과 같이 설명하고 있습니다:
|
||||
|
||||
> Applications define tasks based on both the program's features and the key
|
||||
> things a user is expected to do with them. Tasks should be context-free, in
|
||||
> that the application does not need to be running for them to work. They
|
||||
> should also be the statistically most common actions that a normal user would
|
||||
> perform in an application, such as compose an email message or open the
|
||||
> calendar in a mail program, create a new document in a word processor, launch
|
||||
> an application in a certain mode, or launch one of its subcommands. An
|
||||
> application should not clutter the menu with advanced features that standard
|
||||
> users won't need or one-time actions such as registration. Do not use tasks
|
||||
> for promotional items such as upgrades or special offers.
|
||||
> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을 예측하여 정의합니다.
|
||||
> 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시 context-free를 유지해야 합니다.
|
||||
> 작업은 일반 사용자가 프로그램을 실행하거나 이메일 프로그램으로 이메일을 작성하거나 달력을 불러오고
|
||||
> 워드 프로세서로 새 문서를 작성, 특정 모드, 부속 명령으로 프로그램을 실행하는 등의
|
||||
> 통계적, 일반적으로 가장 많이 사용되는 작업인지를 고려해야 합니다.
|
||||
> 어플리케이션 작업은 일반 유저가 필요로 하지 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다.
|
||||
> 작업에 특별 이벤트 또는 업그레이드 등의 홍보성 작업을 추가하면 안됩니다.
|
||||
>
|
||||
> It is strongly recommended that the task list be static. It should remain the
|
||||
> same regardless of the state or status of the application. While it is
|
||||
> possible to vary the list dynamically, you should consider that this could
|
||||
> confuse the user who does not expect that portion of the destination list to
|
||||
> change.
|
||||
> 작업 리스트는 가능한 한 정적으로 유지되는 것을 적극 권장합니다.
|
||||
> 이것은 동일한 상태 또는 응용 프로그램의 상태에 관계없이 유지되어야 합니다.
|
||||
> 작업 목록은 동적으로 변경할 수 있지만 몇몇 유저는 예상하지 못한 작업 목록 변경에 혼동할 수 있다는 점을 고려해야 합니다.
|
||||
|
||||
__Tasks of Internet Explorer:__
|
||||
__Internet Explorer의 작업:__
|
||||
|
||||
|
||||
|
||||
Unlike the dock menu in OS X which is a real menu, user tasks in Windows work
|
||||
like application shortcuts that when user clicks a task, a program would be
|
||||
executed with specified arguments.
|
||||
OS X의 말 그대로 메뉴로 작동하는 dock menu 와는 달리 Windows의 사용자 작업은 어플리케이션 바로가기처럼 작동합니다.
|
||||
유저가 작업을 클릭할 시 설정한 인자와 함께 새로운 어플리케이션이 실행됩니다.
|
||||
|
||||
To set user tasks for your application, you can use
|
||||
[app.setUserTasks][setusertaskstasks] API:
|
||||
사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] API를 사용하여 구현할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
|
|
@ -124,66 +107,54 @@ app.setUserTasks([
|
|||
]);
|
||||
```
|
||||
|
||||
To clean your tasks list, just call `app.setUserTasks` with empty array:
|
||||
작업 리스트를 비우려면 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어 호출하면 됩니다:
|
||||
|
||||
```javascript
|
||||
app.setUserTasks([]);
|
||||
```
|
||||
|
||||
The user tasks will still show even after your application closes, so the icon
|
||||
and program path specified for a task should exist until your application is
|
||||
uninstalled.
|
||||
사용자 작업 리스트는 어플리케이션이 종료되어도 태스크바에 여전히 보존됩니다. 그러므로 어플리케이션이 삭제되기 전까지 이 기능이 제대로 작동하도록 하기 위해 반드시 프로그램 경로와 아이콘 경로를 지정해야 합니다.
|
||||
|
||||
## Unity 런처 숏컷 기능 (Linux)
|
||||
|
||||
In Unity, you can add custom entries to its launcher via modifying `.desktop`
|
||||
file, see [Adding shortcuts to a launcher][unity-launcher].
|
||||
Unity 환경에선 `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding shortcuts to a launcher][unity-launcher] 가이드를 참고하세요.
|
||||
|
||||
__Launcher shortcuts of Audacious:__
|
||||
__Audacious의 런처 숏컷:__
|
||||
|
||||
|
||||
|
||||
## Taskbar progress 기능 (Windows & Unity)
|
||||
|
||||
On Windows, a taskbar button can be used to display a progress bar. This enables
|
||||
a window to provide progress information to the user without the user having to
|
||||
switch to the window itself.
|
||||
Windows에선 태스크바의 어플리케이션 버튼에 progress bar를 추가할 수 있습니다.
|
||||
이 기능은 사용자가 어플리케이션의 창을 열지 않고도 어플리케이션의 작업의 상태 정보를 시각적으로 보여줄 수 있도록 해줍니다.
|
||||
|
||||
The Unity DE also has a similar feature that allows you to specify the progress
|
||||
bar in the launcher.
|
||||
또한 Unity DE도 런처에 progress bar를 부착할 수 있습니다.
|
||||
|
||||
__Progress bar in taskbar button:__
|
||||
__태스크바 버튼의 progress bar:__
|
||||
|
||||
|
||||
|
||||
__Progress bar in Unity launcher:__
|
||||
__Unity 런처의 progress bar:__
|
||||
|
||||
|
||||
|
||||
To set the progress bar for a Window, you can use the
|
||||
[BrowserWindow.setProgressBar][setprogressbar] API:
|
||||
이 기능은 [BrowserWindow.setProgressBar][setprogressbar] API를 사용하여 구현할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var window = new BrowserWindow({...});
|
||||
window.setProgressBar(0.5);
|
||||
```
|
||||
|
||||
## 윈도우 파일 제시 (OS X)
|
||||
## 윈도우 대표 파일 제시 (OS X)
|
||||
|
||||
On OS X a window can set its represented file, so the file's icon can show in
|
||||
the title bar, and when users Command-Click or Control-Click on the tile a path
|
||||
popup will show.
|
||||
OS X는 윈도우에서 대표 파일을 설정할 수 있습니다. 쉽게 말해 타이틀바에서 파일 아이콘을 볼 수 있을 때 사용자가 Command-Click 또는 Control-Click 할 경우 파일 경로 팝업이 보여집니다.
|
||||
또한 윈도우의 상태도 지정할 수 있습니다. 쉽게 말해 로드된 문서의 수정여부를 타이틀바 파일 아이콘에 표시할 수 있습니다.
|
||||
|
||||
You can also set the edited state of a window so that the file icon can indicate
|
||||
whether the document in this window has been modified.
|
||||
|
||||
__Represented file popup menu:__
|
||||
__대표 파일 팝업 메뉴:__
|
||||
|
||||
<img src="https://cloud.githubusercontent.com/assets/639601/5082061/670a949a-6f14-11e4-987a-9aaa04b23c1d.png" height="232" width="663" >
|
||||
|
||||
To set the represented file of window, you can use the
|
||||
[BrowserWindow.setRepresentedFilename][setrepresentedfilename] and
|
||||
[BrowserWindow.setDocumentEdited][setdocumentedited] APIs:
|
||||
대표 파일 관련 API는 [BrowserWindow.setRepresentedFilename][setrepresentedfilename] 과 [BrowserWindow.setDocumentEdited][setdocumentedited]를 사용할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var window = new BrowserWindow({...});
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# 개발자 콘솔 확장
|
||||
|
||||
어플리케이션의 디버깅을 쉽게 하기 위해, Electron은 기본적으로 [Chrome DevTools Extension][devtools-extension]을 지원합니다.
|
||||
어플리케이션의 디버깅을 쉽게 하기 위해 Electron은 기본적으로 [Chrome DevTools Extension][devtools-extension]을 지원합니다.
|
||||
|
||||
개발자 콘솔 확장기능은 간단하게 사용할 확장기능 플러그인의 소스코드를 다운로드한 후 `BrowserWindow.addDevToolsExtension` API를 이용하여
|
||||
어플리케이션 내에 로드할 수 있습니다. 한가지 주의할 점은 확장기능 사용시 창이 생성될 때 마다 일일이 해당 API를 호출할 필요는 없습니다.
|
||||
|
||||
예시로 [React DevTools Extension](https://github.com/facebook/react-devtools)을 사용하자면, 먼저 소스코드를 다운로드 받아야합니다:
|
||||
예시로 [React DevTools Extension](https://github.com/facebook/react-devtools)을 사용 한다면 먼저 소스코드를 다운로드 받고:
|
||||
|
||||
```bash
|
||||
$ cd /some-directory
|
||||
|
|
@ -18,7 +18,7 @@ $ git clone --recursive https://github.com/facebook/react-devtools.git
|
|||
require('remote').require('browser-window').addDevToolsExtension('/some-directory/react-devtools');
|
||||
```
|
||||
|
||||
확장기능을 unload 하려면, `BrowserWindow.removeDevToolsExtension` API를 사용하여 다음에 콘솔을 다시 열 때 해당 확장기능이 로드되지 않도록 할 수 있습니다:
|
||||
확장기능을 unload 하려면 `BrowserWindow.removeDevToolsExtension` API를 사용하여 다음에 콘솔을 다시 열 때 해당 확장기능이 로드되지 않도록 할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
require('remote').require('browser-window').removeDevToolsExtension('React Developer Tools');
|
||||
|
|
@ -33,12 +33,11 @@ require('remote').require('browser-window').removeDevToolsExtension('React Devel
|
|||
## 백그라운드 페이지
|
||||
|
||||
현재 Electron은 Chrome에서 지원하는 백그라운드 페이지(background pages)를 지원하지 않습니다.
|
||||
몇몇 확장기능은 이 기능에 의존하는 경우가 있는데, 이 경우 해당 확장기능은 Electron에서 작동하지 않을 수 있습니다.
|
||||
몇몇 확장기능은 이 기능에 의존하는 경우가 있는데 이 경우 해당 확장기능은 Electron에서 작동하지 않을 수 있습니다.
|
||||
|
||||
## `chrome.*` API
|
||||
|
||||
몇몇 Chrome 확장기능은 특정 기능을 사용하기 위해 `chrome.*` API를 사용하는데, Electron에선 이 API들을 구현하기 위해 노력했지만,
|
||||
안타깝게도 아직 모든 API가 구현되지는 않았습니다.
|
||||
몇몇 Chrome 확장기능은 특정 기능을 사용하기 위해 `chrome.*` API를 사용하는데, Electron에선 이 API들을 구현하기 위해 노력했지만 안타깝게도 아직 모든 API가 구현되지는 않았습니다.
|
||||
|
||||
아직 모든 API가 구현되지 않았기 때문에 확장기능에서 `chrome.devtools.*` 대신 `chrome.*` API를 사용할 경우 확장기능이 제대로 작동하지 않을 수 있음을 감안해야 합니다.
|
||||
만약 문제가 발생할 경우 Electron의 GitHub repo에 이슈를 올리면 해당 API를 추가하는데 많은 도움이 됩니다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# 온라인/오프라인 이벤트
|
||||
# 온라인/오프라인 이벤트
|
||||
|
||||
온라인/오프라인 이벤트는 다음 예제와 같이 랜더러 프로세스에서 표준 HTML5 API를 이용하여 구현할 수 있습니다.
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ _online-status.html_
|
|||
</html>
|
||||
```
|
||||
|
||||
필요하다면, 이러한 이벤트를 메인 프로세스로 보낼 수도 있습니다.
|
||||
필요한 경우 이 이벤트를 메인 프로세스로 보낼 수도 있습니다.
|
||||
메인 프로세스는 `navigator` 오브젝트를 가지고 있지 않기 때문에 이 이벤트를 직접 사용할 수 없습니다.
|
||||
이는 다음 예제와 같이 electron의 inter-process communication(ipc)유틸리티를 사용하여
|
||||
이벤트를 메인 프로세스로 전달하는 것으로 해결할 수 있습니다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# 시작하기
|
||||
# 시작하기
|
||||
|
||||
## 소개
|
||||
|
||||
|
|
@ -12,34 +12,34 @@ Electron은 자바스크립트와 함께 제공되는 풍부한 네이티브 API
|
|||
### 메인 프로세스
|
||||
|
||||
Electron은 실행될 때 __메인 프로세스__ 로 불리는 `package.json`의 `main` 스크립트를 호출합니다.
|
||||
이 스크립트는 메인 프로세스에서 작동합니다, GUI 컴포넌트를 컨트롤하거나 웹 페이지 창을 생성할 수 있습니다.
|
||||
이 스크립트는 메인 프로세스에서 작동합니다. GUI 컴포넌트를 컨트롤하거나 웹 페이지 창을 생성할 수 있습니다.
|
||||
|
||||
### 랜더러 프로세스
|
||||
|
||||
Electron이 웹페이지를 보여줄 때, Chromium의 multi-processes 구조도 같이 사용됩니다.
|
||||
Electron이 웹페이지를 보여줄 때 Chromium의 multi-processes 구조도 같이 사용됩니다.
|
||||
Electron 프로세스 내에서 작동하는 웹 페이지는 __랜더러 프로세스__ 라고 불립니다.
|
||||
|
||||
보통, 일반 브라우저의 웹 페이지들은 샌드박스가 적용된 환경에서 작동하며 네이티브 리소스에는 접근할 수 없도록 되어 있습니다.
|
||||
보통 일반 브라우저의 웹 페이지들은 샌드박스가 적용된 환경에서 작동하며 네이티브 리소스에는 접근할 수 없도록 되어 있습니다.
|
||||
하지만 Electron은 웹 페이지 내에서 io.js(node.js) API를 사용하여 low-level 수준으로 운영체제와 상호작용할 수 있습니다.
|
||||
|
||||
### 메인 프로세스와 랜더러 프로세스의 차이점
|
||||
|
||||
메인 프로세스는 `BrowserWindow` Class를 이용하여 창을 만들 수 있습니다. `BrowserWindow` 인스턴스는
|
||||
따로 분리된 프로세스에서 랜더링 되며, `BrowserWindow` 인스턴스가 소멸할 때, 해당하는 랜더러 프로세스도 같이 소멸합니다.
|
||||
따로 분리된 프로세스에서 랜더링 되며 `BrowserWindow` 인스턴스가 소멸할 때 해당하는 랜더러 프로세스도 같이 소멸합니다.
|
||||
|
||||
메인 프로세스는 모든 웹 페이지와 그에 해당하는 랜더러 프로세스를 관리하며,
|
||||
메인 프로세스는 모든 웹 페이지와 그에 해당하는 랜더러 프로세스를 관리하며
|
||||
랜더러 프로세스는 각각의 프로세스에 고립되며 웹 페이지의 작동에만 영향을 끼칩니다.
|
||||
|
||||
웹 페이지 내에서 네이티브 GUI 리소스를 관리하는 것은 매우 위험하고,
|
||||
리소스를 누수시킬 수 있기 때문에 웹 페이지 내에서는 네이티브 GUI와 관련된 API를 호출할 수 없도록 되어 있습니다.
|
||||
만약 웹 페이지 내에서 GUI작업이 필요하다면, 메인 프로세스에서 그 작업을 할 수 있도록 통신을 해야합니다.
|
||||
웹 페이지 내에서 네이티브 GUI 리소스를 관리하는 것은 보안에 취약하고 리소스를 누수시킬 수 있기 때문에
|
||||
웹 페이지 내에서는 네이티브 GUI와 관련된 API를 호출할 수 없도록 되어 있습니다.
|
||||
만약 웹 페이지 내에서 GUI작업이 필요하다면 메인 프로세스에서 그 작업을 할 수 있도록 메인 프로세스와 통신을 해야합니다.
|
||||
|
||||
Electron에는 메인 프로세스와 랜더러 프로세스간에 통신을 할 수 있도록 [ipc](../api/ipc-renderer-ko.md) 모듈을 제공하고 있습니다.
|
||||
또한 [remote](../api/remote-ko.md) 모듈을 사용하여 RPC 스타일로 통신할 수도 있습니다.
|
||||
|
||||
## 나의 첫번째 Electron 앱 만들기
|
||||
|
||||
보통, Electron 앱은 다음과 같은 폴더 구조를 가집니다:
|
||||
보통 Electron 앱은 다음과 같은 폴더 구조를 가집니다:
|
||||
|
||||
```text
|
||||
your-app/
|
||||
|
|
@ -48,7 +48,7 @@ your-app/
|
|||
└── index.html
|
||||
```
|
||||
|
||||
`package.json`은 node 모듈의 package.json과 같습니다, 그리고 `main` 필드를 지정하여
|
||||
`package.json`은 node 모듈의 package.json과 같습니다. 그리고 `main` 필드를 지정하여
|
||||
메인 프로세스로 사용할 어플리케이션 시작점을 정의할 수 있습니다.
|
||||
예를 들어 사용할 수 있는 `package.json`은 다음과 같습니다:
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ your-app/
|
|||
}
|
||||
```
|
||||
|
||||
`main.js`에서 창을 만들거나 시스템 이벤트를 처리할 수 있습니다, 대표적인 예제로 다음과 같이 작성할 수 있습니다:
|
||||
`main.js`에서 창을 만들거나 시스템 이벤트를 처리할 수 있습니다. 대표적인 예제로 다음과 같이 작성할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var app = require('app'); // 어플리케이션 기반을 조작 하는 모듈.
|
||||
|
|
@ -69,7 +69,7 @@ var BrowserWindow = require('browser-window'); // 네이티브 브라우저 창
|
|||
// Electron 개발자에게 crash-report를 보냄.
|
||||
require('crash-reporter').start();
|
||||
|
||||
// 윈도우 객체를 전역에 유지합니다, 만약 이렇게 하지 않으면,
|
||||
// 윈도우 객체를 전역에 유지합니다. 만약 이렇게 하지 않으면
|
||||
// 자바스크립트 GC가 일어날 때 창이 자동으로 닫혀버립니다.
|
||||
var mainWindow = null;
|
||||
|
||||
|
|
@ -94,15 +94,15 @@ app.on('ready', function() {
|
|||
|
||||
// 창이 닫히면 호출됩니다.
|
||||
mainWindow.on('closed', function() {
|
||||
// 윈도우 객체의 참조를 삭제합니다, 보통 멀티 윈도우 지원을 위해
|
||||
// 윈도우 객체를 배열에 저장하는 경우가 있는데, 이 경우
|
||||
// 윈도우 객체의 참조를 삭제합니다 보통 멀티 윈도우 지원을 위해
|
||||
// 윈도우 객체를 배열에 저장하는 경우가 있는데 이 경우
|
||||
// 해당하는 모든 윈도우 객체의 참조를 삭제해 주어야 합니다.
|
||||
mainWindow = null;
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
마지막으로, 사용자에게 보여줄 `index.html` 웹 페이지의 예제입니다:
|
||||
마지막으로 사용자에게 보여줄 `index.html` 웹 페이지의 예제입니다:
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
|
|
@ -120,7 +120,7 @@ app.on('ready', function() {
|
|||
|
||||
## 앱 실행하기
|
||||
|
||||
앱을 작성한 후, [어플리케이션 배포](./application-distribution-ko.md) 가이드를 따라 앱을 패키징 하고
|
||||
앱을 작성한 후 [어플리케이션 배포](./application-distribution-ko.md) 가이드를 따라 앱을 패키징 하고
|
||||
패키징한 앱을 실행해 볼 수 있습니다. 또한 Electron 실행파일을 다운로드 받아 바로 실행해 볼 수도 있습니다.
|
||||
|
||||
Windows의 경우:
|
||||
|
|
|
|||
|
|
@ -10,10 +10,10 @@ Electron에선 node.js 네이티브 모듈이 지원됩니다. 하지만 Electro
|
|||
Node v0.11.x 버전부터는 V8 API의 중대한 변경이 있었습니다. 하지만 일반적으로 모든 네이티브 모듈은 Node v0.10.x 버전을 타겟으로 작성 되었기 때문에
|
||||
Node v0.11.x 버전에선 작동하지 않습니다. Electron은 내부적으로 Node v0.11.13 버전을 사용합니다. 그래서 위에서 설명한 문제가 발생합니다.
|
||||
|
||||
이 문제를 해결하기 위해, 모듈이 Node v0.11.x 버전을 지원할 수 있도록 해야합니다.
|
||||
현재 [많은 모듈들](https://www.npmjs.org/browse/depended/nan)이 안정적으로 두 버전 모두 지원하고 있지만,
|
||||
이 문제를 해결하기 위해 모듈이 Node v0.11.x 버전을 지원할 수 있도록 해야합니다.
|
||||
현재 [많은 모듈들](https://www.npmjs.org/browse/depended/nan)이 안정적으로 두 버전 모두 지원하고 있지만
|
||||
오래된 모듈의 경우 Node v0.10.x 버전만을 지원하고 있습니다.
|
||||
예를들어 [nan](https://github.com/rvagg/nan) 모듈을 사용해야 하는 경우, Node v0.11.x 버전으로 포팅 할 필요가 있습니다.
|
||||
예를들어 [nan](https://github.com/rvagg/nan) 모듈을 사용해야 하는 경우 Node v0.11.x 버전으로 포팅 할 필요가 있습니다.
|
||||
|
||||
## 네이티브 모듈 설치하는 방법
|
||||
|
||||
|
|
@ -31,15 +31,13 @@ npm install --save-dev electron-rebuild
|
|||
|
||||
### node-gyp을 이용한 방법
|
||||
|
||||
Node 모듈을 `node-gyp`를 사용하여 Electron을 타겟으로 빌드할 땐, `node-gyp`에 헤더 다운로드 주소와 버전을 알려주어야합니다:
|
||||
Node 모듈을 `node-gyp`를 사용하여 Electron을 타겟으로 빌드할 땐 `node-gyp`에 헤더 다운로드 주소와 버전을 알려주어야합니다:
|
||||
|
||||
```bash
|
||||
$ cd /path-to-module/
|
||||
$ HOME=~/.electron-gyp node-gyp rebuild --target=0.25.0 --arch=ia64 --dist-url=https://atom.io/download/atom-shell
|
||||
```
|
||||
|
||||
|
||||
|
||||
`HOME=~/.electron-gyp`은 변경할 헤더의 위치를 찾습니다. `--target=0.25.0`은 Electron의 버전입니다.
|
||||
`--dist-url=...`은 헤더를 다운로드 하는 주소입니다. `--arch=ia64`는 64비트 시스템을 타겟으로 빌드 한다는 것을 `node-gyp`에게 알려줍니다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,16 @@
|
|||
# Pepper 플래시 플러그인 사용하기
|
||||
# Pepper 플래시 플러그인 사용하기
|
||||
|
||||
필요하다면 Pepper 플래시 플러그인을 사용할 수 있습니다. Electron에서 pepper 플래시 플러그인을 사용하기 위해서는, 따로 pepper 플래시 플러그인의 위치를 지정해 주어야합니다.
|
||||
필요하다면 Pepper 플래시 플러그인을 사용할 수 있습니다. Electron에서 pepper 플래시 플러그인을 사용하기 위해선 따로 pepper 플래시 플러그인의 위치를 지정해 주어야합니다.
|
||||
|
||||
## 플래시 플러그인 준비하기
|
||||
## 플래시 플러그인 준비하기
|
||||
|
||||
크롬 브라우저의 `chrome://plugins` 페이지에 접속한 후 `세부정보`에서 플래시 플러그인의 위치와 버전을 찾을 수 있습니다.
|
||||
Electron에서 플래시 플러그인을 지원하기 위해선 이 두 가지를 복사해 와야 합니다.
|
||||
크롬 브라우저의 `chrome://plugins` 페이지에 접속한 후 `세부정보`에서 플래시 플러그인의 위치와 버전을 찾을 수 있습니다.
|
||||
Electron에서 플래시 플러그인을 지원하기 위해선 이 두 가지를 복사해 와야 합니다.
|
||||
|
||||
## Electron 스위치 추가
|
||||
## Electron 스위치 추가
|
||||
|
||||
플러그인을 사용하기 위해 직접적으로 `--ppapi-flash-path` 와 `ppapi-flash-version` 플래그를 ready 이벤트가 호출되기 전에 추가해야합니다.
|
||||
그리고 `browser-window`에 `plugins` 스위치도 추가해야합니다.
|
||||
플러그인을 사용하기 위해 직접적으로 `--ppapi-flash-path` 와 `ppapi-flash-version` 플래그를 ready 이벤트가 호출되기 전에 추가해야합니다.
|
||||
그리고 `browser-window`에 `plugins` 스위치도 추가해야합니다.
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
|
|
@ -30,10 +30,10 @@ app.on('window-all-closed', function() {
|
|||
}
|
||||
});
|
||||
|
||||
// 플래시 플러그인의 위치를 설정합니다.
|
||||
// Windows의 경우, /path/to/pepflashplayer.dll
|
||||
// Mac의 경우, /path/to/PepperFlashPlayer.plugin
|
||||
// Linux의 경우, /path/to/libpepflashplayer.so
|
||||
// 플래시 플러그인의 위치를 설정합니다.
|
||||
// Windows의 경우, /path/to/pepflashplayer.dll
|
||||
// Mac의 경우, /path/to/PepperFlashPlayer.plugin
|
||||
// Linux의 경우, /path/to/libpepflashplayer.so
|
||||
app.commandLine.appendSwitch('ppapi-flash-path', '/path/to/libpepflashplayer.so');
|
||||
|
||||
// Specify flash version, for example, v17.0.0.169
|
||||
|
|
@ -52,8 +52,8 @@ app.on('ready', function() {
|
|||
});
|
||||
```
|
||||
|
||||
## `<webview>` 태그를 이용하여 플러그인을 활성화
|
||||
`plugins` 속성을 `<webview>` 태그에 추가합니다.
|
||||
## `<webview>` 태그를 이용하여 플러그인을 활성화
|
||||
`plugins` 속성을 `<webview>` 태그에 추가합니다.
|
||||
```html
|
||||
<webview src="http://www.adobe.com/software/flash/about/" plugins></webview>
|
||||
```
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@
|
|||
[ChromeDriver - WebDriver for Chrome][chrome-driver]로 부터 인용:
|
||||
|
||||
> WebDriver는 많은 브라우저에서 웹 앱을 자동적으로 테스트하는 툴입니다.
|
||||
> 이 툴은 웹 페이지를 자동으로 탐색하고, 유저 폼을 사용하거나, 자바스크립트를 실행하는 등의 작업을 수행할 수 있습니다.
|
||||
> 이 툴킷은 웹 페이지를 자동으로 탐색하고 유저 폼을 사용하거나 자바스크립트를 실행하는 등의 작업을 수행할 수 있습니다.
|
||||
> ChromeDriver는 Chromium의 WebDriver wire 프로토콜 스텐드얼론 서버 구현입니다.
|
||||
> Chromium 과 WebDriver 팀 멤버에 의해 개발되었습니다.
|
||||
|
||||
Electron의 [releases](https://github.com/atom/electron/releases) 페이지에서 `chromedriver` 릴리즈 압축파일을 찾을 수 있습니다.
|
||||
`chromedriver`의 Electron 배포판과 upstream과의 차이는 없습니다.
|
||||
`chromedriver`와 Electron을 함께 사용하려면, 몇가지 설정이 필요합니다.
|
||||
`chromedriver`와 Electron을 함께 사용하려면 몇가지 설정이 필요합니다.
|
||||
|
||||
또한 releases에는 `chromedriver`를 포함하여 주 버전만 업데이트 됩니다. (예시: `vX.X.0` releases)
|
||||
왜냐하면 `chromedriver`는 Electron 자체에서 자주 업데이트하지 않기 때문입니다.
|
||||
|
|
@ -29,7 +29,7 @@ Starting ChromeDriver (v2.10.291558) on port 9515
|
|||
Only local connections are allowed.
|
||||
```
|
||||
|
||||
포트 `9515`를 기억하세요, 나중에 사용합니다
|
||||
곧 사용하므로 포트 `9515`를 기억해 놓습니다.
|
||||
|
||||
### 2. WebDriverJS 설치
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ $ npm install selenium-webdriver
|
|||
### 3. 크롬 드라이버에 연결
|
||||
|
||||
`selenium-webdriver`를 Electron과 같이 사용할 땐 기본적으로 upstream과 같습니다.
|
||||
한가지 다른점이 있다면 수동으로 크롬 드라이버 연결에 대해 설정하고 , Electron 실행파일의 위치를 전달합니다:
|
||||
한가지 다른점이 있다면 수동으로 크롬 드라이버 연결에 대해 설정하고 Electron 실행파일의 위치를 전달합니다:
|
||||
|
||||
```javascript
|
||||
var webdriver = require('selenium-webdriver');
|
||||
|
|
@ -68,7 +68,7 @@ driver.quit();
|
|||
|
||||
## 작업환경
|
||||
|
||||
따로 Electron을 다시 빌드하지 않는다면, 간단히 어플리케이션을 Electron의 리소스 디렉터리에
|
||||
따로 Electron을 다시 빌드하지 않는 경우 간단히 어플리케이션을 Electron의 리소스 디렉터리에
|
||||
[배치](https://github.com/atom/electron/blob/master/docs/tutorial/application-distribution-ko.md)하여 바로 테스트 할 수 있습니다.
|
||||
|
||||
[chrome-driver]: https://sites.google.com/a/chromium.org/chromedriver/
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue