Fix typos, add more files
This commit is contained in:
Plusb Preco
parent
bf5b084945
commit
ebb031dafe
45 changed files with 3450 additions and 239 deletions
|
|
@ -1,4 +1,4 @@
|
|||
# Accelerator
|
||||
# Accelerator
|
||||
|
||||
Accelerator는 키보드 단축키를 표현하는 문자열입니다, 여러 혼합키와 키코드를 `+` 문자를
|
||||
이용하여 결합할 수 있습니다.
|
||||
|
|
|
|||
289
docs/api/app-ko.md
Normal file
289
docs/api/app-ko.md
Normal file
|
|
@ -0,0 +1,289 @@
|
|||
# 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.md) gets blurred.
|
||||
|
||||
## Event: browser-window-focus
|
||||
|
||||
* `event` Event
|
||||
* `window` BrowserWindow
|
||||
|
||||
Emitted when a [browserWindow](browser-window.md) gets focused.
|
||||
|
||||
## 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-atom-shell-installer](https://github.com/atom/grunt-atom-shell-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.
|
||||
1022
docs/api/browser-window-ko.md
Normal file
1022
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 @@
|
|||
# Supported Chrome command line switches
|
||||
|
||||
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.md
|
||||
[append-switch]: app.md#appcommandlineappendswitchswitch-value
|
||||
[ready]: app.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');
|
||||
```
|
||||
90
docs/api/clipboard-ko.md
Normal file
90
docs/api/clipboard-ko.md
Normal file
|
|
@ -0,0 +1,90 @@
|
|||
# clipboard
|
||||
|
||||
The `clipboard` provides methods to do copy/paste operations. An example of
|
||||
writing a string to clipboard:
|
||||
|
||||
```javascript
|
||||
var clipboard = require('clipboard');
|
||||
clipboard.writeText('Example String');
|
||||
```
|
||||
|
||||
On X Window systems, there is also a selection clipboard, to manipulate in it
|
||||
you need to pass `selection` to each method:
|
||||
|
||||
```javascript
|
||||
var clipboard = require('clipboard');
|
||||
clipboard.writeText('Example String', 'selection');
|
||||
console.log(clipboard.readText('selection'));
|
||||
```
|
||||
|
||||
## clipboard.readText([type])
|
||||
|
||||
* `type` String
|
||||
|
||||
Returns the content in clipboard as plain text.
|
||||
|
||||
## clipboard.writeText(text[, type])
|
||||
|
||||
* `text` String
|
||||
* `type` String
|
||||
|
||||
Writes the `text` into clipboard as plain text.
|
||||
|
||||
## clipboard.readHtml([type])
|
||||
|
||||
* `type` String
|
||||
|
||||
Returns the content in clipboard as markup.
|
||||
|
||||
## clipboard.writeHtml(markup[, type])
|
||||
|
||||
* `markup` String
|
||||
* `type` String
|
||||
|
||||
Writes the `markup` into clipboard.
|
||||
|
||||
## clipboard.readImage([type])
|
||||
|
||||
* `type` String
|
||||
|
||||
Returns the content in clipboard as [NativeImage](native-image.md).
|
||||
|
||||
## clipboard.writeImage(image[, type])
|
||||
|
||||
* `image` [NativeImage](native-image.md)
|
||||
* `type` String
|
||||
|
||||
Writes the `image` into clipboard.
|
||||
|
||||
## clipboard.clear([type])
|
||||
|
||||
* `type` String
|
||||
|
||||
Clears everything in clipboard.
|
||||
|
||||
## clipboard.availableFormats([type])
|
||||
|
||||
Returns an array of supported `format` for the clipboard `type`.
|
||||
|
||||
## clipboard.has(data[, type])
|
||||
|
||||
* `data` String
|
||||
* `type` String
|
||||
|
||||
Returns whether clipboard supports the format of specified `data`.
|
||||
|
||||
```javascript
|
||||
var clipboard = require('clipboard');
|
||||
console.log(clipboard.has('<p>selection</p>'));
|
||||
```
|
||||
|
||||
**Note:** This API is experimental and could be removed in future.
|
||||
|
||||
## clipboard.read(data[, type])
|
||||
|
||||
* `data` String
|
||||
* `type` String
|
||||
|
||||
Reads the `data` in clipboard.
|
||||
|
||||
**Note:** This API is experimental and could be removed in future.
|
||||
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.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.
|
||||
30
docs/api/file-object-ko.md
Normal file
30
docs/api/file-object-ko.md
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
# `File` object
|
||||
|
||||
The DOM's File interface provides abstraction around native files, in order to
|
||||
let users work on native files directly with HTML5 file API, Electron has
|
||||
added a `path` attribute to `File` interface which exposes the file's real path
|
||||
on filesystem.
|
||||
|
||||
Example on getting real path of a dragged file:
|
||||
|
||||
```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.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.
|
||||
49
docs/api/global-shortcut-ko.md
Normal file
49
docs/api/global-shortcut-ko.md
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
# global-shortcut
|
||||
|
||||
The `global-shortcut` module can register/unregister a global keyboard shortcut
|
||||
in operating system, so that you can customize the operations for various shortcuts.
|
||||
Note that the shortcut is global, even if the app does not get focused, it will still work.
|
||||
|
||||
```javascript
|
||||
var globalShortcut = require('global-shortcut');
|
||||
|
||||
// Register a 'ctrl+x' shortcut listener.
|
||||
var ret = globalShortcut.register('ctrl+x', function() { console.log('ctrl+x is pressed'); })
|
||||
|
||||
if (!ret) {
|
||||
console.log('registration failed');
|
||||
}
|
||||
|
||||
// Check whether a shortcut is registered.
|
||||
console.log(globalShortcut.isRegistered('ctrl+x'));
|
||||
|
||||
// Unregister a shortcut.
|
||||
globalShortcut.unregister('ctrl+x');
|
||||
|
||||
// Unregister all shortcuts.
|
||||
globalShortcut.unregisterAll();
|
||||
```
|
||||
|
||||
## globalShortcut.register(accelerator, callback)
|
||||
|
||||
* `accelerator` [Accelerator](accelerator.md)
|
||||
* `callback` Function
|
||||
|
||||
Registers a global shortcut of `accelerator`, the `callback` would be called when
|
||||
the registered shortcut is pressed by user.
|
||||
|
||||
## globalShortcut.isRegistered(accelerator)
|
||||
|
||||
* `accelerator` [Accelerator](accelerator.md)
|
||||
|
||||
Returns `true` or `false` depending on if the shortcut `accelerator` is registered.
|
||||
|
||||
## globalShortcut.unregister(accelerator)
|
||||
|
||||
* `accelerator` [Accelerator](accelerator.md)
|
||||
|
||||
Unregisters the global shortcut of `keycode`.
|
||||
|
||||
## globalShortcut.unregisterAll()
|
||||
|
||||
Unregisters all the global shortcuts.
|
||||
49
docs/api/ipc-main-process-ko.md
Normal file
49
docs/api/ipc-main-process-ko.md
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
# ipc (main process)
|
||||
|
||||
Handles asynchronous and synchronous message sent from a renderer process (web
|
||||
page).
|
||||
|
||||
The messages sent from a renderer would be emitted to this module, the event name
|
||||
is the `channel` when sending message. To reply a synchronous message, you need
|
||||
to set `event.returnValue`, to send an asynchronous back to the sender, you can
|
||||
use `event.sender.send(...)`.
|
||||
|
||||
It's also possible to send messages from main process to the renderer process,
|
||||
see [WebContents.send](browser-window.md#webcontentssendchannel-args) for more.
|
||||
|
||||
An example of sending and handling messages:
|
||||
|
||||
```javascript
|
||||
// In main process.
|
||||
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
|
||||
// In renderer process (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
|
||||
|
||||
Assign to this to return an value to synchronous messages.
|
||||
|
||||
### Event.sender
|
||||
|
||||
The `WebContents` that sent the message.
|
||||
29
docs/api/ipc-renderer-ko.md
Normal file
29
docs/api/ipc-renderer-ko.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# ipc (renderer)
|
||||
|
||||
The `ipc` module provides a few methods so you can send synchronous and
|
||||
asynchronous messages to the main process, and also receive messages sent from
|
||||
main process. If you want to make use of modules of main process from renderer
|
||||
process, you might consider using the [remote](remote.md) module.
|
||||
|
||||
See [ipc (main process)](ipc-main-process.md) for examples.
|
||||
|
||||
## ipc.send(channel[, args...])
|
||||
|
||||
Send `args..` to the renderer via `channel` in asynchronous message, the main
|
||||
process can handle it by listening to the `channel` event of `ipc` module.
|
||||
|
||||
## ipc.sendSync(channel[, args...])
|
||||
|
||||
Send `args..` to the renderer via `channel` in synchronous message, and returns
|
||||
the result sent from main process. The main process can handle it by listening to
|
||||
the `channel` event of `ipc` module, and returns by setting `event.returnValue`.
|
||||
|
||||
**Note:** Usually developers should never use this API, since sending
|
||||
synchronous message would block the whole renderer process.
|
||||
|
||||
## ipc.sendToHost(channel[, args...])
|
||||
|
||||
Like `ipc.send` but the message will be sent to the host page instead of the
|
||||
main process.
|
||||
|
||||
This is mainly used by the page in `<webview>` to communicate with host page.
|
||||
|
|
@ -1,13 +1,13 @@
|
|||
# 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)
|
||||
|
|
@ -15,6 +15,6 @@
|
|||
* `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.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.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
|
||||
```
|
||||
139
docs/api/native-image-ko.md
Normal file
139
docs/api/native-image-ko.md
Normal file
|
|
@ -0,0 +1,139 @@
|
|||
# NativeImage
|
||||
|
||||
In Electron for the APIs that take images, you can pass either file paths or
|
||||
`NativeImage` instances. When passing `null`, an empty image will be used.
|
||||
|
||||
For example, when creating a tray or setting a window's icon, you can pass an image
|
||||
file path as a `String`:
|
||||
|
||||
```javascript
|
||||
var appIcon = new Tray('/Users/somebody/images/icon.png');
|
||||
var window = new BrowserWindow({icon: '/Users/somebody/images/window.png'});
|
||||
```
|
||||
|
||||
Or read the image from the clipboard:
|
||||
|
||||
```javascript
|
||||
var clipboard = require('clipboard');
|
||||
var image = clipboard.readImage();
|
||||
var appIcon = new Tray(image);
|
||||
```
|
||||
|
||||
## Supported formats
|
||||
|
||||
Currently `PNG` and `JPEG` are supported. It is recommended to use `PNG`
|
||||
because of its support for transparency and lossless compression.
|
||||
|
||||
## High resolution image
|
||||
|
||||
On platforms that have high-DPI support, you can append `@2x` after image's
|
||||
file name's base name to mark it as a high resolution image.
|
||||
|
||||
For example if `icon.png` is a normal image that has standard resolution, the
|
||||
`icon@2x.png` would be treated as a high resolution image that has double DPI
|
||||
density.
|
||||
|
||||
If you want to support displays with different DPI density at the same time, you
|
||||
can put images with different sizes in the same folder, and use the filename
|
||||
without DPI suffixes, like this:
|
||||
|
||||
```text
|
||||
images/
|
||||
├── icon.png
|
||||
├── icon@2x.png
|
||||
└── icon@3x.png
|
||||
```
|
||||
|
||||
|
||||
```javascript
|
||||
var appIcon = new Tray('/Users/somebody/images/icon.png');
|
||||
```
|
||||
|
||||
Following suffixes as DPI denses are also supported:
|
||||
|
||||
* `@1x`
|
||||
* `@1.25x`
|
||||
* `@1.33x`
|
||||
* `@1.4x`
|
||||
* `@1.5x`
|
||||
* `@1.8x`
|
||||
* `@2x`
|
||||
* `@2.5x`
|
||||
* `@3x`
|
||||
* `@4x`
|
||||
* `@5x`
|
||||
|
||||
## Template image
|
||||
|
||||
Template images consist of black and clear colors (and an alpha channel).
|
||||
Template images are not intended to be used as standalone images and are usually
|
||||
mixed with other content to create the desired final appearance.
|
||||
|
||||
The most common case is to use template image for menu bar icon so it can adapt
|
||||
to both light and dark menu bars.
|
||||
|
||||
Template image is only supported on Mac.
|
||||
|
||||
To mark an image as template image, its filename should end with the word
|
||||
`Template`, examples are:
|
||||
|
||||
* `xxxTemplate.png`
|
||||
* `xxxTemplate@2x.png`
|
||||
|
||||
## nativeImage.createEmpty()
|
||||
|
||||
Creates an empty `NativeImage` instance.
|
||||
|
||||
## nativeImage.createFromPath(path)
|
||||
|
||||
* `path` String
|
||||
|
||||
Creates a new `NativeImage` instance from a file located at `path`.
|
||||
|
||||
## nativeImage.createFromBuffer(buffer[, scaleFactor])
|
||||
|
||||
* `buffer` [Buffer][buffer]
|
||||
* `scaleFactor` Double
|
||||
|
||||
Creates a new `NativeImage` instance from `buffer`. The `scaleFactor` is 1.0 by
|
||||
default.
|
||||
|
||||
## nativeImage.createFromDataUrl(dataUrl)
|
||||
|
||||
* `dataUrl` String
|
||||
|
||||
Creates a new `NativeImage` instance from `dataUrl`.
|
||||
|
||||
## Class: NativeImage
|
||||
|
||||
This class is used to represent an image.
|
||||
|
||||
### NativeImage.toPng()
|
||||
|
||||
Returns a [Buffer][buffer] that contains image's `PNG` encoded data.
|
||||
|
||||
### NativeImage.toJpeg(quality)
|
||||
|
||||
* `quality` Integer
|
||||
|
||||
Returns a [Buffer][buffer] that contains image's `JPEG` encoded data.
|
||||
|
||||
### NativeImage.toDataUrl()
|
||||
|
||||
Returns the data URL of image.
|
||||
|
||||
### NativeImage.isEmpty()
|
||||
|
||||
Returns whether the image is empty.
|
||||
|
||||
### NativeImage.getSize()
|
||||
|
||||
Returns the size of the image.
|
||||
|
||||
[buffer]: https://iojs.org/api/buffer.html#buffer_class_buffer
|
||||
|
||||
### NativeImage.setTemplateImage(option)
|
||||
|
||||
* `option` Boolean
|
||||
|
||||
Marks the image as template image.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# power-monitor
|
||||
# power-monitor
|
||||
|
||||
`power-monitor` 모듈은 PC의 파워 상태를 나타냅니다. (주로 노트북 등에서 사용됩니다)
|
||||
이 모듈은 메인 프로세스에서만 사용할 수 있으며, (remote 모듈(RPC)을 사용해도 작동이 됩니다)
|
||||
|
|
|
|||
13
docs/api/process-ko.md
Normal file
13
docs/api/process-ko.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
# Process object
|
||||
|
||||
The `process` object in Electron has the following differences from the one in
|
||||
upstream node:
|
||||
|
||||
* `process.type` String - Process's type, can be `browser` (i.e. main process) or `renderer`.
|
||||
* `process.versions['electron']` String - Version of Electron.
|
||||
* `process.versions['chrome']` String - Version of Chromium.
|
||||
* `process.resourcesPath` String - Path to JavaScript source code.
|
||||
|
||||
## process.hang
|
||||
|
||||
Causes the main thread of the current process hang.
|
||||
121
docs/api/protocol-ko.md
Normal file
121
docs/api/protocol-ko.md
Normal file
|
|
@ -0,0 +1,121 @@
|
|||
# protocol
|
||||
|
||||
The `protocol` module can register a new protocol or intercept an existing
|
||||
protocol, so you can customize the response to the requests for various protocols.
|
||||
|
||||
An example of implementing a protocol that has the same effect with the
|
||||
`file://` protocol:
|
||||
|
||||
```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));
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
**Note:** This module can only be used after the `ready` event
|
||||
was emitted.
|
||||
|
||||
## protocol.registerProtocol(scheme, handler)
|
||||
|
||||
* `scheme` String
|
||||
* `handler` Function
|
||||
|
||||
Registers a custom protocol of `scheme`, the `handler` would be called with
|
||||
`handler(request)` when the a request with registered `scheme` is made.
|
||||
|
||||
You need to return a request job in the `handler` to specify which type of
|
||||
response you would like to send.
|
||||
|
||||
## protocol.unregisterProtocol(scheme)
|
||||
|
||||
* `scheme` String
|
||||
|
||||
Unregisters the custom protocol of `scheme`.
|
||||
|
||||
## protocol.registerStandardSchemes(value)
|
||||
|
||||
* `value` Array
|
||||
|
||||
`value` is an array of custom schemes to be registered to the standard.
|
||||
|
||||
## protocol.isHandledProtocol(scheme)
|
||||
|
||||
* `scheme` String
|
||||
|
||||
Returns whether the `scheme` can be handled already.
|
||||
|
||||
## protocol.interceptProtocol(scheme, handler)
|
||||
|
||||
* `scheme` String
|
||||
* `handler` Function
|
||||
|
||||
Intercepts an existing protocol with `scheme`, returning `null` or `undefined`
|
||||
in `handler` would use the original protocol handler to handle the request.
|
||||
|
||||
## protocol.uninterceptProtocol(scheme)
|
||||
|
||||
* `scheme` String
|
||||
|
||||
Unintercepts a protocol.
|
||||
|
||||
## Class: protocol.RequestFileJob(path)
|
||||
|
||||
* `path` String
|
||||
|
||||
Create a request job which would query a file of `path` and set corresponding
|
||||
mime types.
|
||||
|
||||
## Class: protocol.RequestStringJob(options)
|
||||
|
||||
* `options` Object
|
||||
* `mimeType` String - Default is `text/plain`
|
||||
* `charset` String - Default is `UTF-8`
|
||||
* `data` String
|
||||
|
||||
Create a request job which sends a string as response.
|
||||
|
||||
## Class: protocol.RequestBufferJob(options)
|
||||
|
||||
* `options` Object
|
||||
* `mimeType` String - Default is `application/octet-stream`
|
||||
* `encoding` String - Default is `UTF-8`
|
||||
* `data` Buffer
|
||||
|
||||
Create a request job which sends a buffer as response.
|
||||
|
||||
## Class: protocol.RequestHttpJob(options)
|
||||
|
||||
* `options` Object
|
||||
* `url` String
|
||||
* `method` String - Default is `GET`
|
||||
* `referrer` String
|
||||
|
||||
Send a request to `url` and pipe the response back.
|
||||
|
||||
## Class: protocol.RequestErrorJob(code)
|
||||
|
||||
* `code` Integer
|
||||
|
||||
Create a request job which sets appropriate network error message to console.
|
||||
Default message is `net::ERR_NOT_IMPLEMENTED`. Code should be in the following
|
||||
range.
|
||||
|
||||
* Ranges:
|
||||
* 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
|
||||
|
||||
Check the [network error list](https://code.google.com/p/chromium/codesearch#chromium/src/net/base/net_error_list.h) for code and message relations.
|
||||
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.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.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.
|
||||
39
docs/api/shell-ko.md
Normal file
39
docs/api/shell-ko.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
# shell
|
||||
|
||||
The `shell` module provides functions related to desktop integration.
|
||||
|
||||
An example of opening a URL in default browser:
|
||||
|
||||
```javascript
|
||||
var shell = require('shell');
|
||||
shell.openExternal('https://github.com');
|
||||
```
|
||||
|
||||
## shell.showItemInFolder(fullPath)
|
||||
|
||||
* `fullPath` String
|
||||
|
||||
Show the given file in a file manager. If possible, select the file.
|
||||
|
||||
## shell.openItem(fullPath)
|
||||
|
||||
* `fullPath` String
|
||||
|
||||
Open the given file in the desktop's default manner.
|
||||
|
||||
## shell.openExternal(url)
|
||||
|
||||
* `url` String
|
||||
|
||||
Open the given external protocol URL in the desktop's default manner. (For
|
||||
example, mailto: URLs in the default mail user agent.)
|
||||
|
||||
## shell.moveItemToTrash(fullPath)
|
||||
|
||||
* `fullPath` String
|
||||
|
||||
Move the given file to trash and returns boolean status for the operation.
|
||||
|
||||
## shell.beep()
|
||||
|
||||
Play the beep sound.
|
||||
44
docs/api/synopsis-ko.md
Normal file
44
docs/api/synopsis-ko.md
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
# Synopsis
|
||||
|
||||
All of [node.js's built-in modules](http://nodejs.org/api/) are available in
|
||||
Electron, and third-party node modules are fully supported too (including the
|
||||
[native modules](../tutorial/using-native-node-modules.md)).
|
||||
|
||||
Electron also provides some extra built-in modules for developing native
|
||||
desktop applications. Some modules are only available on the main process, some
|
||||
are only available on the renderer process, and some can be used on both processes.
|
||||
The basic rule is: if a module is GUI or low-level system related, then it should
|
||||
be only available on the main process. You need to be familiar with the concept of
|
||||
[main process vs. renderer process](../tutorial/quick-start.md#the-main-process)
|
||||
scripts to be able to use those modules.
|
||||
|
||||
The main process script is just like a normal `node.js` script:
|
||||
|
||||
```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');
|
||||
});
|
||||
```
|
||||
|
||||
The web page is no different than a normal web page, except for the extra
|
||||
ability to use node modules:
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<body>
|
||||
<script>
|
||||
var remote = require('remote');
|
||||
console.log(remote.require('app').getVersion());
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
To run your app, read [Run your app](../tutorial/quick-start.md#run-your-app).
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Tray
|
||||
# Tray
|
||||
|
||||
`Tray`는 OS의 알림영역에 아이콘을 표시합니다. 보통 컨텍스트 메뉴(context menu)를 같이 사용합니다.
|
||||
|
||||
|
|
|
|||
66
docs/api/web-frame-ko.md
Normal file
66
docs/api/web-frame-ko.md
Normal file
|
|
@ -0,0 +1,66 @@
|
|||
# web-frame
|
||||
|
||||
The `web-frame` module can custom the rendering of current web page.
|
||||
|
||||
An example of zooming current page to 200%.
|
||||
|
||||
```javascript
|
||||
var webFrame = require('web-frame');
|
||||
webFrame.setZoomFactor(2);
|
||||
```
|
||||
|
||||
## webFrame.setZoomFactor(factor)
|
||||
|
||||
* `factor` Number - Zoom factor
|
||||
|
||||
Changes the zoom factor to the specified factor, zoom factor is
|
||||
zoom percent / 100, so 300% = 3.0.
|
||||
|
||||
## webFrame.getZoomFactor()
|
||||
|
||||
Returns the current zoom factor.
|
||||
|
||||
## webFrame.setZoomLevel(level)
|
||||
|
||||
* `level` Number - Zoom level
|
||||
|
||||
Changes the zoom level to the specified level, 0 is "original size", and each
|
||||
increment above or below represents zooming 20% larger or smaller to default
|
||||
limits of 300% and 50% of original size, respectively.
|
||||
|
||||
## webFrame.getZoomLevel()
|
||||
|
||||
Returns the current zoom level.
|
||||
|
||||
## webFrame.setSpellCheckProvider(language, autoCorrectWord, provider)
|
||||
|
||||
* `language` String
|
||||
* `autoCorrectWord` Boolean
|
||||
* `provider` Object
|
||||
|
||||
Sets a provider for spell checking in input fields and text areas.
|
||||
|
||||
The `provider` must be an object that has a `spellCheck` method that returns
|
||||
whether the word passed is correctly spelled.
|
||||
|
||||
An example of using [node-spellchecker][spellchecker] as provider:
|
||||
|
||||
```javascript
|
||||
require('web-frame').setSpellCheckProvider("en-US", true, {
|
||||
spellCheck: function(text) {
|
||||
return !(require('spellchecker').isMisspelled(text));
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
## webFrame.registerUrlSchemeAsSecure(scheme)
|
||||
|
||||
* `scheme` String
|
||||
|
||||
Sets the `scheme` as secure scheme.
|
||||
|
||||
Secure schemes do not trigger mixed content warnings. For example, `https` and
|
||||
`data` are secure schemes because they cannot be corrupted by active network
|
||||
attackers.
|
||||
|
||||
[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
|
||||
|
||||
|
|
|
|||
60
docs/api/window-open-ko.md
Normal file
60
docs/api/window-open-ko.md
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
# `window.open` function
|
||||
|
||||
When `window.open` is called to create a new window in web page, a new instance
|
||||
of `BrowserWindow` will be created for the `url`, and a proxy will be returned
|
||||
to `window.open` to let the page to have limited control over it.
|
||||
|
||||
The proxy only has some limited standard functionality implemented to be
|
||||
compatible with traditional web pages, for full control of the created window
|
||||
you should create a `BrowserWindow` directly.
|
||||
|
||||
## window.open(url, [frameName[, features]])
|
||||
|
||||
* `url` String
|
||||
* `frameName` String
|
||||
* `features` String
|
||||
|
||||
Creates a new window and returns an instance of `BrowserWindowProxy` class.
|
||||
|
||||
## window.opener.postMessage(message, targetOrigin)
|
||||
|
||||
* `message` String
|
||||
* `targetOrigin` String
|
||||
|
||||
Sends a message to the parent window with the specified origin or `*` for no
|
||||
origin preference.
|
||||
|
||||
## Class: BrowserWindowProxy
|
||||
|
||||
### BrowserWindowProxy.blur()
|
||||
|
||||
Removes focus from the child window.
|
||||
|
||||
### BrowserWindowProxy.close()
|
||||
|
||||
Forcefully closes the child window without calling its unload event.
|
||||
|
||||
### BrowserWindowProxy.closed
|
||||
|
||||
Set to true after the child window gets closed.
|
||||
|
||||
### BrowserWindowProxy.eval(code)
|
||||
|
||||
* `code` String
|
||||
|
||||
Evaluates the code in the child window.
|
||||
|
||||
### BrowserWindowProxy.focus()
|
||||
|
||||
Focuses the child window (brings the window to front).
|
||||
|
||||
### BrowserWindowProxy.postMessage(message, targetOrigin)
|
||||
|
||||
* `message` String
|
||||
* `targetOrigin` String
|
||||
|
||||
Sends a message to the child window with the specified origin or `*` for no
|
||||
origin preference.
|
||||
|
||||
In addition to these methods, the child window implements `window.opener` object
|
||||
with no properties and a single method:
|
||||
|
|
@ -1,49 +1,34 @@
|
|||
# NW.js와 기술적으로 다른점 (이전 node-webkit)
|
||||
# NW.js와 기술적으로 다른점 (이전 node-webkit)
|
||||
|
||||
__알림: Electron은 이전까지 Atom Shell로 불려졌습니다.__
|
||||
|
||||
Like NW.js, Electron provides a platform to write desktop applications
|
||||
with JavaScript and HTML and has Node integration to grant access to low level
|
||||
system in web pages.
|
||||
NW.js 처럼 Electron은 JavaScript와 HTML 그리고 Node 통합환경을 제공함으로써 웹 페이지에서 저수준 시스템에 접근할 수 있는 웹 기반 데스크탑 어플리케이션을 작성할 수 있도록 합니다.
|
||||
|
||||
But there are also fundamental differences between the two projects that make
|
||||
Electron a completely separate product from NW.js:
|
||||
하지만 Electron과 NW.js는 근본적인 개발흐름의 차이도 있습니다:
|
||||
|
||||
__1. 어플리케이션의 엔트리 포인트__
|
||||
|
||||
In NW.js, the main entry of an application is a web page. You specify a
|
||||
main page in the `package.json` and it is opened in a browser window as
|
||||
the application's main window.
|
||||
NW.js에선 어플리케이션의 엔트리 포인트로 웹 페이지를 사용합니다.
|
||||
`package.json`내의 main 필드에 메인 웹 페이지(index.html) 파일을 지정하면 어플리케이션의 메인 윈도우로 열리게 됩니다.
|
||||
|
||||
In Electron, the entry point is a JavaScript script. Instead of
|
||||
providing a URL directly, you manually create a browser window and load
|
||||
an HTML file using the API. You also need to listen to window events
|
||||
to decide when to quit the application.
|
||||
Electron에선 JavaScript를 엔트리 포인트로 사용합니다. URL을 직접 제공하는 대신 API를 사용하여 직접 브라우저 창과 HTML 파일을 로드할 수 있습니다.
|
||||
또한 윈도우의 종료시기를 결정하는 이벤트를 리스닝해야합니다.
|
||||
|
||||
Electron works more like the Node.js runtime. Electron's APIs are lower level
|
||||
so you can use it for browser testing in place of [PhantomJS](http://phantomjs.org/).
|
||||
Electron은 Node.js 런타임과 비슷하게 작동합니다. Electron의 API는 저수준이기에 브라우저 테스팅을 위해 [PhantomJS](http://phantomjs.org/)를 사용할 수도 있습니다.
|
||||
|
||||
__2. 빌드 시스템__
|
||||
|
||||
In order to avoid the complexity of building the whole Chromium, Electron uses
|
||||
[libchromiumcontent](https://github.com/brightray/libchromiumcontent) to access
|
||||
Chromium's Content API. libchromiumcontent is a single, shared library that
|
||||
includes the Chromium Content module and all its dependencies. Users don't
|
||||
need a powerful machine to build Electron.
|
||||
Electron은 Chromium의 모든것을 빌드하는 복잡성을 피하기 위해 [libchromiumcontent](https://github.com/brightray/libchromiumcontent)를 사용하여
|
||||
Chromium의 Content API에 접근합니다. libchromiumcontent은 단일 공유 라이브러리이고 Chromium Content 모듈과 종속성 라이브러리들을 포함합니다.
|
||||
유저는 Electron을 빌드 하기 위해 높은 사양의 빌드용 컴퓨터를 구비할 필요가 없습니다.
|
||||
|
||||
__3. Node 통합__
|
||||
|
||||
In NW.js, the Node integration in web pages requires patching Chromium to
|
||||
work, while in Electron we chose a different way to integrate libuv loop with
|
||||
each platform's message loop to avoid hacking Chromium. See the
|
||||
[`node_bindings`](../../atom/common/) code for how that was done.
|
||||
NW.js는 웹 페이지에서 require를 사용할 수 있도록 Chromium을 패치했습니다. 한편 Electron은 Chromium의 해킹을 방지하기 위해 libuv loop와 각 플랫폼의 메시지 루프에 통합하는 등의 다른 방법을 채택하였습니다.
|
||||
[`node_bindings`](../../atom/common/) 코드를 보면 이 부분이 어떻게 구현됬는지를 알 수 있습니다.
|
||||
|
||||
__4. 다중 컨텍스트__
|
||||
|
||||
If you are an experienced NW.js user, you should be familiar with the
|
||||
concept of Node context and web context. These concepts were invented because
|
||||
of how NW.js was implemented.
|
||||
만약 NW.js를 사용해본적이 있다면 Node context와 Web context의 개념을 잘 알고 있을겁니다. 이 개념은 NW.js가 구현된 방식에 따라 만들어졌습니다.
|
||||
|
||||
By using the [multi-context](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)
|
||||
feature of Node, Electron doesn't introduce a new JavaScript context in web
|
||||
pages.
|
||||
Node의 [다중 컨텍스트](http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/)를 사용할 경우 Electron은 웹 페이지에서 새로운 JavaScript 컨텍스트를 생성하지 않습니다.
|
||||
|
|
|
|||
|
|
@ -2,16 +2,14 @@
|
|||
|
||||
## 빌드전 요구사양
|
||||
|
||||
* Python 2.7.x. Some distributions like CentOS still use Python 2.6.x
|
||||
so you may need to check your Python version with `python -V`.
|
||||
* Node.js v0.12.x. There are various ways to install Node. One can download
|
||||
source code from [Node.js] (http://nodejs.org) and compile from source.
|
||||
Doing so permits installing Node to your own home directory as a standard user.
|
||||
Or try repositories such as [NodeSource] (https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories)
|
||||
* Clang 3.4 or later
|
||||
* Development headers of GTK+ and libnotify
|
||||
* 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의 개발용 헤더
|
||||
|
||||
On Ubuntu, install the following libraries:
|
||||
Ubuntu를 사용하고 있다면 다음 커맨드로 설치하면 합니다:
|
||||
|
||||
```bash
|
||||
$ sudo apt-get install build-essential clang libdbus-1-dev libgtk2.0-dev \
|
||||
|
|
@ -20,14 +18,12 @@ $ sudo apt-get install build-essential clang libdbus-1-dev libgtk2.0-dev \
|
|||
libxss1 gcc-multilib g++-multilib
|
||||
```
|
||||
|
||||
Other distributions may offer similar packages for installation via package
|
||||
managers such as yum. Or one can compile from source code.
|
||||
|
||||
다른 배포판의 경우 yum과 같은 패키지 매니저를 통해 패키지를 설치 할 수 있습니다. 패키지의 이름은 대부분 비슷할 것입니다.
|
||||
또는 소스코드를 내려받아 직접 빌드하는 방법도 있습니다.
|
||||
|
||||
## 가상머신을 사용하여 빌드 하는 경우
|
||||
|
||||
If you plan to build electron on a virtual machine, you will need a fixed-size
|
||||
device container of at least 25 gigabytes in size.
|
||||
만약 Electron을 가상머신으로 빌드 할 계획이라면 해당 가상머신의 스토리지를 최소 25GB 이상을 확보해 놓아야 합니다.
|
||||
|
||||
|
||||
## 코드 가져오기
|
||||
|
|
@ -38,10 +34,10 @@ $ git clone https://github.com/atom/electron.git
|
|||
|
||||
## 부트 스트랩
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. You must have Python 2.7.x for the script to succeed.
|
||||
Downloading certain files could take a long time. Notice that we are using
|
||||
`ninja` to build Electron so there is no `Makefile` generated.
|
||||
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
|
||||
스크립트가 정상적으로 작동하기 위해선 Python 2.7.x 버전이 필요합니다.
|
||||
아마 다운로드 작업이 상당히 많은 시간을 소요할 것입니다.
|
||||
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 `Makefile`은 생성되지 않습니다.
|
||||
|
||||
```bash
|
||||
$ cd electron
|
||||
|
|
@ -50,48 +46,42 @@ $ ./script/bootstrap.py -v
|
|||
|
||||
## 빌드 하기
|
||||
|
||||
If you would like to build both `Release` and `Debug` targets:
|
||||
`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py
|
||||
```
|
||||
|
||||
This script will cause a very large Electron executable to be placed in
|
||||
the directory `out/R`. The file size is in excess of 1.3 gigabytes. This
|
||||
happens because the Release target binary contains debugging symbols.
|
||||
To reduce the file size, run the `create-dist.py` script:
|
||||
이 스크립트는 `out/R` 디렉터리에 크기가 매우 큰 Electron 실행 파일을 배치합니다. 파일 크기는 1.3GB를 초과합니다.
|
||||
이러한 문제가 발생하는 이유는 Release 타겟 바이너리가 디버그 심볼을 포함하기 때문입니다.
|
||||
파일 크기를 줄이려면 `create-dist.py` 스크립트를 실행하세요:
|
||||
|
||||
```bash
|
||||
$ ./script/create-dist.py
|
||||
```
|
||||
|
||||
This will put a working distribution with much smaller file sizes in
|
||||
the `dist` directory. After running the create-dist.py script, you
|
||||
may want to remove the 1.3+ gigabyte binary which is still in out/R.
|
||||
이 스크립트는 매우 작은 배포판을 `dist` 디렉터리에 생성합니다.
|
||||
create-dist.py 스크립트를 실행한 이후 1.3GB를 초과하는 공간을 차지하는 out/R 폴더의 실행파일 바이너리는 삭제해도 됩니다.
|
||||
|
||||
You can also build the `Debug` target only:
|
||||
`Debug` 타겟만 빌드 할 수도 있습니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
After building is done, you can find the `electron` debug binary
|
||||
under `out/D`.
|
||||
|
||||
빌드가 모두 끝나면 `out/D` 디렉터리에서 `electron` 디버그 바이너리를 찾을 수 있습니다.
|
||||
|
||||
## 정리 하기
|
||||
|
||||
|
||||
To clean the build files:
|
||||
빌드 파일들을 정리합니다:
|
||||
|
||||
```bash
|
||||
$ ./script/clean.py
|
||||
```
|
||||
|
||||
|
||||
## 문제 해결
|
||||
|
||||
Make sure you have installed all the build dependencies.
|
||||
개발 종속성 라이브러리들을 제대로 설치했는지 확인하세요.
|
||||
|
||||
## 테스트
|
||||
|
||||
|
|
|
|||
|
|
@ -6,8 +6,7 @@
|
|||
* [Xcode](https://developer.apple.com/technologies/tools/) >= 5.1
|
||||
* [node.js](http://nodejs.org) (external).
|
||||
|
||||
If you are using the python downloaded by Homebrew, you also need to install
|
||||
following python modules:
|
||||
만약 Homebrew를 이용해 파이선을 설치했다면 다음 파이선 모듈도 같이 설치해야 합니다:
|
||||
|
||||
* pyobjc
|
||||
|
||||
|
|
@ -19,9 +18,8 @@ $ git clone https://github.com/atom/electron.git
|
|||
|
||||
## 부트 스트랩
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. Notice that we're using `ninja` to build Electron so
|
||||
there is no Xcode project generated.
|
||||
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
|
||||
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Xcode 프로젝트는 생성되지 않습니다.
|
||||
|
||||
```bash
|
||||
$ cd electron
|
||||
|
|
@ -30,24 +28,23 @@ $ ./script/bootstrap.py -v
|
|||
|
||||
## 빌드 하기
|
||||
|
||||
Build both `Release` and `Debug` targets:
|
||||
`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py
|
||||
```
|
||||
|
||||
You can also only build the `Debug` target:
|
||||
`Debug` 타겟만 빌드 할 수도 있습니다:
|
||||
|
||||
```bash
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
After building is done, you can find `Electron.app` under `out/D`.
|
||||
빌드가 모두 끝나면 `out/D` 디렉터리에서 `Electron.app` 실행 파일을 찾을 수 있습니다.
|
||||
|
||||
## 32비트 지원
|
||||
|
||||
Electron can only be built for 64bit target on OS X, and there is no plan to
|
||||
support 32bit OS X in future.
|
||||
Electron은 현재 OS X 64비트 빌드만 지원하고 있습니다. 그리고 앞으로도 OS X 32비트는 지원할 계획이 없습니다.
|
||||
|
||||
## 테스트
|
||||
|
||||
|
|
|
|||
|
|
@ -1,25 +1,23 @@
|
|||
# 빌드 설명서 (Windows)
|
||||
# 빌드 설명서 (Windows)
|
||||
|
||||
## 빌드전 요구 사항
|
||||
|
||||
* Windows 7 / Server 2008 R2 or higher
|
||||
* Visual Studio 2013 - [download VS 2013 Community Edition for
|
||||
free](http://www.visualstudio.com/products/visual-studio-community-vs)
|
||||
* 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)에서 Electron을 빌드할 수 있는 timebombed Windows 버전을 확인할 수 있습니다.
|
||||
|
||||
If you don't have a Windows installation at the moment,
|
||||
[modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads) has
|
||||
timebombed versions of Windows that you can use to build Electron.
|
||||
|
||||
The building of Electron is done entirely with command-line scripts, so you
|
||||
can use any editor you like to develop Electron, but it also means you can
|
||||
not use Visual Studio for the development. Support of building with Visual
|
||||
Studio will come in the future.
|
||||
Electron은 전적으로 command-line 스크립트를 사용하여 빌드합니다. 그렇기에 Electron을 개발하는데 아무런 에디터나 사용할 수 있습니다.
|
||||
하지만 이 말은 Visual Studio를 개발을 위해 사용할 수 없다는 말이 됩니다. 나중에 Visual Studio를 이용한 빌드 방법도 제공할 예정입니다.
|
||||
|
||||
**Note:** Even though Visual Studio is not used for building, it's still
|
||||
**required** because we need the build toolchains it provided.
|
||||
**참고:** Visual Studio가 빌드에 사용되지 않더라도 제공된 빌드 툴체인이 **필수적으로** 사용되므로 여전히 필요합니다.
|
||||
|
||||
## 코드 가져오기
|
||||
|
||||
|
|
@ -29,9 +27,8 @@ git clone https://github.com/atom/electron.git
|
|||
|
||||
## 부트 스트랩
|
||||
|
||||
The bootstrap script will download all necessary build dependencies and create
|
||||
build project files. Notice that we're using `ninja` to build Electron so
|
||||
there is no Visual Studio project generated.
|
||||
부트스트랩 스크립트는 필수적인 빌드 종속성 라이브러리들을 모두 다운로드하고 프로젝트 파일을 생성합니다.
|
||||
참고로 Electron은 빌드 툴체인으로 `ninja`를 사용하므로 Visual Studio 프로젝트는 생성되지 않습니다.
|
||||
|
||||
```powershell
|
||||
cd electron
|
||||
|
|
@ -40,30 +37,29 @@ python script\bootstrap.py -v
|
|||
|
||||
## 빌드 하기
|
||||
|
||||
Build both Release and Debug targets:
|
||||
`Release` 와 `Debug` 두 타겟 모두 빌드 합니다:
|
||||
|
||||
```powershell
|
||||
python script\build.py
|
||||
```
|
||||
|
||||
You can also only build the Debug target:
|
||||
`Debug` 타겟만 빌드 할 수도 있습니다:
|
||||
|
||||
```powershell
|
||||
python script\build.py -c D
|
||||
```
|
||||
|
||||
After building is done, you can find `atom.exe` under `out\D`.
|
||||
빌드가 모두 끝나면 `out/D` 디렉터리에서 `atom.exe` 실행 파일을 찾을 수 있습니다.
|
||||
|
||||
## 64비트 빌드
|
||||
|
||||
To build for the 64bit target, you need to pass `--target_arch=x64` when running
|
||||
the bootstrap script:
|
||||
64비트를 타겟으로 빌드 하려면 부트스트랩 스크립트를 실행할 때 `--target_arch=x64` 인자를 같이 넘겨주면 됩니다:
|
||||
|
||||
```powershell
|
||||
python script\bootstrap.py -v --target_arch=x64
|
||||
```
|
||||
|
||||
The other building steps are exactly the same.
|
||||
다른 빌드 단계도 정확하게 같습니다.
|
||||
|
||||
## 테스트
|
||||
|
||||
|
|
@ -75,17 +71,15 @@ python script\test.py
|
|||
|
||||
### Command xxxx not found
|
||||
|
||||
If you encountered an error like `Command xxxx not found`, you may try to use
|
||||
the `VS2012 Command Prompt` console to execute the build scripts.
|
||||
만약 `Command xxxx not found`와 같은 형식의 에러가 발생했다면 `VS2012 Command Prompt` 콘솔로 빌드 스크립트를 실행해볼 필요가 있습니다.
|
||||
|
||||
### Fatal internal compiler error: C1001
|
||||
|
||||
Make sure you have the latest Visual Studio update installed.
|
||||
Visual Studio가 업데이트까지 완벽하게 설치된 최신버전인지 확인하세요.
|
||||
|
||||
### Assertion failed: ((handle))->activecnt >= 0
|
||||
|
||||
If building under Cygwin, you may see `bootstrap.py` failed with following
|
||||
error:
|
||||
Cygwin에서 빌드 할 경우 `bootstrap.py` 스크립트가 다음의 에러와 함께 빌드에 실패할 수 있습니다:
|
||||
|
||||
```
|
||||
Assertion failed: ((handle))->activecnt >= 0, file src\win\pipe.c, line 1430
|
||||
|
|
@ -102,9 +96,8 @@ Traceback (most recent call last):
|
|||
subprocess.CalledProcessError: Command '['npm.cmd', 'install']' returned non-zero exit status 3
|
||||
```
|
||||
|
||||
This is caused by a bug when using Cygwin python and Win32 node together. The
|
||||
solution is to use the Win32 python to execute the bootstrap script (supposing
|
||||
you have installed python under `C:\Python27`):
|
||||
이 버그는 Cygwin python과 Win32 node를 같이 사용할 경우 발생합니다.
|
||||
부트스트랩 스크립트에서 Win32 python을 사용함으로써 이 문제를 해결할 수 있습니다 (`C:\Python27` 디렉터리에 python이 설치되었다는 것을 가정하면):
|
||||
|
||||
```bash
|
||||
/cygdrive/c/Python27/python.exe script/bootstrap.py
|
||||
|
|
@ -112,11 +105,11 @@ you have installed python under `C:\Python27`):
|
|||
|
||||
### LNK1181: cannot open input file 'kernel32.lib'
|
||||
|
||||
Try reinstalling 32bit node.js.
|
||||
32bit node.js를 다시 설치하세요.
|
||||
|
||||
### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'
|
||||
|
||||
Simply making that directory [should fix the problem](http://stackoverflow.com/a/25095327/102704):
|
||||
간단하게 해당 디렉터리를 생성하면 [문제가 해결될 겁니다](http://stackoverflow.com/a/25095327/102704):
|
||||
|
||||
```powershell
|
||||
mkdir ~\AppData\Roaming\npm
|
||||
|
|
@ -124,5 +117,4 @@ mkdir ~\AppData\Roaming\npm
|
|||
|
||||
### node-gyp is not recognized as an internal or external command
|
||||
|
||||
You may get this error if you are using Git Bash for building, you should use
|
||||
PowerShell or VS2012 Command Prompt instead.
|
||||
Git Bash로 빌드 했을 때 이러한 에러가 발생할 수 있습니다. 반드시 PowerShell이나 VS2012 Command Prompt에서 빌드를 진행해야 합니다.
|
||||
|
|
|
|||
|
|
@ -1,64 +1,51 @@
|
|||
# 빌드 시스템 개요
|
||||
# 빌드 시스템 개요
|
||||
|
||||
Electron uses `gyp` for project generation, and `ninja` for building, project
|
||||
configurations can be found in `.gyp` and `.gypi` files.
|
||||
Electron은 프로젝트 생성을 위해 `gyp`를 사용하며 `ninja`를 이용하여 빌드합니다.
|
||||
프로젝트 설정은 `.gyp` 와 `.gypi` 파일에서 볼 수 있습니다.
|
||||
|
||||
## Gyp 파일들
|
||||
## gyp 파일들
|
||||
|
||||
Following `gyp` files contain the main rules of building Electron:
|
||||
Electron을 빌드 할 때 `gyp` 파일들은 다음과 같은 규칙을 따릅니다:
|
||||
|
||||
* `atom.gyp` defines how Electron itself is built.
|
||||
* `common.gypi` adjusts the build configurations of Node to make it build
|
||||
together with Chromium.
|
||||
* `vendor/brightray/brightray.gyp` defines how `brightray` is built, and
|
||||
includes the default configurations of linking with Chromium.
|
||||
* `vendor/brightray/brightray.gypi` includes general build configurations about
|
||||
building.
|
||||
* `atom.gyp`는 Electron의 빌드 과정 자체를 정의합니다.
|
||||
* `common.gypi`는 Node가 Chromium과 함께 빌드될 수 있도록 조정한 빌드 설정입니다.
|
||||
* `vendor/brightray/brightray.gyp`는 `brightray`의 빌드 과정을 정의하고 Chromium과의 링킹에 대한 기본적인 설정을 포함합니다.
|
||||
* `vendor/brightray/brightray.gypi`는 빌드에 대한 일반적인 설정이 포함되어 있습니다.
|
||||
|
||||
## 구성요소 빌드
|
||||
|
||||
Since Chromium is quite a large project, the final linking stage would take
|
||||
quite a few minutes, making it hard for development. In order to solve this,
|
||||
Chromium introduced the "component build", which builds each component as a
|
||||
separate shared library, making linking very quick but sacrificing file size
|
||||
and performance.
|
||||
Chromium은 꽤나 큰 프로젝트입니다. 이 때문에 최종 링킹 작업은 상당한 시간이 소요될 수 있습니다.
|
||||
이러한 문제로 인해 개발 시 빌드 작업을 까다롭게 만듭니다. 이 문제를 해결하기 위해 Chromium은 "component build"를 도입했습니다.
|
||||
이는 각각의 컴포넌트를 각각 따로 분리하여 공유 라이브러리로 빌드 합니다. 이렇게 되면 링킹작업은 매우 빨라지지만 파일 크기와 성능이 느려집니다.
|
||||
|
||||
In Electron we took a very similar approach: for `Debug` builds, the binary
|
||||
will be linked to shared library version of Chromium's components to achieve
|
||||
fast linking time; for `Release` builds, the binary will be linked to the static
|
||||
library versions, so we can have the best possible binary size and performance.
|
||||
Electron도 상당히 비슷한 접근을 했습니다:
|
||||
`Debug`빌드 시 바이너리는 공유 라이브러리 버전의 Chromium 컴포넌트를 사용해서 링크 속도를 높이고
|
||||
`Release`빌드 시엔 정적 라이브러리 버전의 컴포넌트를 사용합니다.
|
||||
이렇게 각 빌드의 단점을 상호 보완하여 디버그 시 빌드 속도는 향상되고 배포판 빌드 시 공유 라이브러리의 단점은 제거했습니다.
|
||||
|
||||
## 부트스트랩 최소화
|
||||
|
||||
All of Chromium's prebuilt binaries are downloaded when running the bootstrap
|
||||
script. By default both static libraries and shared libraries will be
|
||||
downloaded and the final size should be between 800MB and 2GB according to the
|
||||
platform.
|
||||
모든 사전 빌드 된 Chromium 바이너리들은 부트스트랩 스크립트가 실행될 때 다운로드됩니다.
|
||||
기본적으로 공유 라이브러리와 정적 라이브러리 모두 다운로드되며 최종 전체 파일 크기는 플랫폼에 따라 800MB에서 2GB까지 차지합니다.
|
||||
|
||||
If you only want to build Electron quickly for testing or development, you
|
||||
can only download the shared library versions by passing the `--dev` parameter:
|
||||
만약 빠르게 Electron의 개발 또는 테스트만 하고 싶다면 `--dev` 플래그를 추가하여 공유 라이브러리만 다운로드할 수 있습니다:
|
||||
|
||||
```bash
|
||||
$ ./script/bootstrap.py --dev
|
||||
$ ./script/build.py -c D
|
||||
```
|
||||
|
||||
## Two-phrase 프로젝트 생성
|
||||
## 프로젝트 생성 (two-phrase)
|
||||
|
||||
Electron links with different sets of libraries in `Release` and `Debug`
|
||||
builds, however `gyp` doesn't support configuring different link settings for
|
||||
different configurations.
|
||||
Electron은 `Release`와 `Debug` 빌드가 서로 다른 라이브러리 링크 방식을 사용합니다.
|
||||
그러나 `gyp`는 따로 빌드 설정을 분리하여 라이브러리 링크 방식을 정의하는 것을 지원하지 않습니다.
|
||||
|
||||
To work around this Electron uses a `gyp` variable
|
||||
`libchromiumcontent_component` to control which link settings to use, and only
|
||||
generates one target when running `gyp`.
|
||||
이러한 문제를 해결하기 위해 Electron은 링크 설정을 제어하는 `gyp` 변수 `libchromiumcontent_component`를 사용하고 `gyp`를 실행할 때 단 하나의 타겟만을 생성합니다.
|
||||
|
||||
## 타겟 이름
|
||||
|
||||
Unlike most projects that use `Release` and `Debug` as target names, Electron
|
||||
uses `R` and `D` instead. This is because `gyp` randomly crashes if there is
|
||||
only one `Release` or `Debug` build configuration is defined, and Electron has
|
||||
to only generate one target for one time as stated above.
|
||||
많은 프로젝트에서 타겟 이름을 `Release` 와 `Debug`를 사용하는데 반해 Electron은 `R`과 `D`를 대신 사용합니다.
|
||||
이유는 가끔 알 수 없는 이유(randomly)로 `Release` 와 `Debug` 중 하나만 빌드 설정에 정의되어 있을때 `gyp`가 크래시를 일으키는데
|
||||
전술한 바와 같이 Electron은 한번에 한개의 타겟만을 생성할 수 있기 때문입니다.
|
||||
|
||||
This only affects developers, if you are only building Electron for rebranding
|
||||
you are not affected.
|
||||
이 문제는 개발자에게만 영향을 미칩니다. 만약 단순히 Electron을 rebranding 하기 위해 빌드 한다면 이 문제에 신경 쓸 필요가 없습니다.
|
||||
|
|
|
|||
|
|
@ -8,15 +8,15 @@ C++과 Python스크립트는 Chromium의 [코딩 스타일](http://www.chromium.
|
|||
|
||||
## 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)가 있습니다.
|
||||
|
|
|
|||
|
|
@ -39,8 +39,8 @@ Electron의 소스 코드는 몇 개의 파트로 분리되어 있습니다. 우
|
|||
## 그외 디렉터리 구조
|
||||
|
||||
* **script** - 개발목적으로 사용되는 빌드, 패키징, 테스트, 기타등을 실행하는 스크립트.
|
||||
* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트, `script`와는 다르게 유저로부터 직접 실행되지 않는 스크립트들을 이곳에 넣습니다.
|
||||
* **vendor** - 소스코드의 서드파티 종속성 코드, 소스 코드 디렉터리가 겹쳐 혼란을 일으킬 수 있기 때문에,
|
||||
* **tools** - gyp 파일에서 사용되는 헬퍼 스크립트 `script`와는 다르게 유저로부터 직접 실행되지 않는 스크립트들을 이곳에 넣습니다.
|
||||
* **vendor** - 소스코드의 서드파티 종속성 코드 소스 코드 디렉터리가 겹쳐 혼란을 일으킬 수 있기 때문에
|
||||
우리는 `third_party`와 같은 Chromium 소스 코드 디렉터리에서 사용된 폴더 이름을 사용하지 않았습니다.
|
||||
* **node_modules** - 빌드에 사용되는 node 서드파티 모듈.
|
||||
* **out** - `ninja`의 임시 출력 디렉터리.
|
||||
|
|
|
|||
|
|
@ -23,12 +23,12 @@ electron/resources/app
|
|||
└── index.html
|
||||
```
|
||||
|
||||
그리고 `Electron.app`을 실행하면 (Linux에선 `electron` Windows에선 `electron.exe`입니다), Electron은 해당 앱을 실행시킵니다.
|
||||
그리고 `Electron.app`을 실행하면(Linux에선 `electron` Windows에선 `electron.exe`입니다) Electron은 해당 앱을 실행시킵니다.
|
||||
최종 사용자에게는 이 `electron` 폴더(Electron.app)를 배포하면 됩니다.
|
||||
|
||||
## asar로 앱 패키징 하기
|
||||
|
||||
소스파일 전체를 복사해서 배포하는 것과는 별개로, [asar](https://github.com/atom/asar) 아카이브를 통해
|
||||
소스파일 전체를 복사해서 배포하는 것과는 별개로 [asar](https://github.com/atom/asar) 아카이브를 통해
|
||||
어플리케이션의 소스코드가 사용자에게 노출되는 것을 방지할 수 있습니다.
|
||||
|
||||
`asar` 아카이브를 사용할 땐 단순히 `app` 폴더 대신에 어플리케이션을 패키징한 `app.asar` 파일로 대체하면됩니다.
|
||||
|
|
@ -52,7 +52,7 @@ electron/resources/
|
|||
|
||||
## 다운로드한 바이너리의 리소스를 앱에 맞게 수정하기
|
||||
|
||||
어플리케이션을 Electron에 번들링한 후, 해당 어플리케이션에 맞게 리브랜딩 할 수 있습니다.
|
||||
어플리케이션을 Electron에 번들링한 후 해당 어플리케이션에 맞게 리브랜딩 할 수 있습니다.
|
||||
|
||||
### Windows
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 어플리케이션 패키징
|
||||
|
||||
어플리케이션의 리소스와 소스코드를 유저로부터 보호하기 위해, 약간의 구조 변경으로 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
|
||||
어플리케이션의 리소스와 소스코드를 유저로부터 보호하기 위해 약간의 구조 변경으로 어플리케이션을 [asar][asar] 아카이브로 패키징 할 수 있습니다.
|
||||
|
||||
## `asar` 아카이브 생성
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ $ asar pack your-app app.asar
|
|||
|
||||
## `asar` 아카이브 사용하기
|
||||
|
||||
Electron은 두가지의 API를 가지고 있습니다: Node.js로 부터 제공된 Node API, Chromium으로부터 제공된 Web API.
|
||||
Electron은 Node.js로 부터 제공된 Node API와 Chromium으로부터 제공된 Web API 두가지의 API를 가지고 있습니다.
|
||||
두 API 모두 `asar`에서 읽어들일 수 있도록 지원합니다.
|
||||
|
||||
### Node API
|
||||
|
|
@ -31,7 +31,7 @@ Electron은 두가지의 API를 가지고 있습니다: Node.js로 부터 제공
|
|||
`fs.readFile` 와 `require` 같은 Node API들을 지원하기 위해 Electron에선 `asar` 아카이브가 가상의 디렉터리 구조를 가지도록
|
||||
패치했습니다. 그래서 아카이브 내부에서 리소스들을 정상적인 파일 시스템처럼 접근할 수 있습니다.
|
||||
|
||||
예를들어, `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면:
|
||||
예를들어 `/path/to`라는 경로에 `example.asar`라는 아카이브가 있다고 가정하면:
|
||||
|
||||
```bash
|
||||
$ asar list /path/to/example.asar
|
||||
|
|
@ -73,10 +73,10 @@ win.loadUrl('file:///path/to/example.asar/static/index.html');
|
|||
|
||||
### Web API
|
||||
|
||||
웹 페이지 내에선, 아카이브 내의 파일을 `file:` 프로토콜을 사용하여 요청할 수 있습니다.
|
||||
웹 페이지 내에선 아카이브 내의 파일을 `file:` 프로토콜을 사용하여 요청할 수 있습니다.
|
||||
이 또한 Node API와 같이 가상 디렉터리 구조를 가집니다.
|
||||
|
||||
예를들어, jQuery의 `$.get`을 사용하여 파일을 가져올 수 있습니다:
|
||||
예를들어 jQuery의 `$.get`을 사용하여 파일을 가져올 수 있습니다:
|
||||
|
||||
```html
|
||||
<script>
|
||||
|
|
@ -89,7 +89,7 @@ $.get('file:///path/to/example.asar/file.txt', function(data) {
|
|||
|
||||
### `asar` 아카이브를 일반 파일로 취급하기
|
||||
|
||||
`asar` 아카이브의 체크섬(checksum)등을 검사하기 위해선, `asar` 아카이브를 파일 그대로 읽어들여야 할 필요가 있습니다.
|
||||
`asar` 아카이브의 체크섬(checksum)등을 검사하기 위해선 `asar` 아카이브를 파일 그대로 읽어들여야 할 필요가 있습니다.
|
||||
이 작업을 하기 위해 `original-fs`라고 하는 빌트인 모듈을 `fs` 모듈 대신에 사용할 수 있습니다.
|
||||
이 모듈은 `asar` 지원이 빠져있습니다. 즉 파일 그대로를 읽어들입니다:
|
||||
|
||||
|
|
@ -100,24 +100,20 @@ originalFs.readFileSync('/path/to/example.asar');
|
|||
|
||||
## Node API의 한계
|
||||
|
||||
`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만, 여전히 저수준(low-level) Node API 때문에 한계가 있습니다.
|
||||
|
||||
Even though we tried hard to make `asar` archives in the Node API work like
|
||||
directories as much as possible, there are still limitations due to the
|
||||
low-level nature of the Node API.
|
||||
`asar` 아카이브를 Node API가 최대한 디렉터리 구조로 작동하도록 노력해왔지만 여전히 저수준(low-level nature) Node API 때문에 한계가 있습니다.
|
||||
|
||||
### 아카이브는 읽기 전용입니다
|
||||
|
||||
아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만, `asar` 아카이브에선 작동하지 않습니다.
|
||||
아카이브는 수정할 수 없으며 기본적으로는 Node API로 파일을 수정할 수 있지만 `asar` 아카이브에선 작동하지 않습니다.
|
||||
|
||||
### 아카이브 안의 디렉터리를 작업 경로로 설정하면 안됩니다
|
||||
|
||||
`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만, 그것은 실제 파일시스템의 디렉터리가 아닌 가상의 디렉터리입니다.
|
||||
`asar` 아카이브는 디렉터리처럼 사용할 수 있도록 구현되었지만 그것은 실제 파일시스템의 디렉터리가 아닌 가상의 디렉터리입니다.
|
||||
그런 이유로 몇몇 API에서 지원하는 `cwd` 옵션을 `asar` 아카이브 안의 디렉터리 경로로 지정하면 나중에 문제가 발생할 수 있습니다.
|
||||
|
||||
### 특정 API로 인한 예외적인 압축 해제
|
||||
|
||||
많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를 가져올 수 있으나,
|
||||
많은 `fs` API가 `asar` 아카이브의 압축을 해제하지 않고 바로 아카이브를 읽거나 정보를 가져올 수 있으나
|
||||
몇몇 API는 시스템의 실제 파일의 경로를 기반으로 작동하므로 이 API들을 사용할 땐 Electron은
|
||||
이 API가 원할하게 작동할 수 있도록 하기 위해 임시경로에 해당 파일들의 압축을 해제합니다. 이 작업은 약간의 오버헤드를 불러 일으킬 수 있습니다.
|
||||
|
||||
|
|
@ -128,25 +124,25 @@ low-level nature of the Node API.
|
|||
* `fs.openSync`
|
||||
* `process.dlopen` - Used by `require` on native modules
|
||||
|
||||
### `fs.stat`의 잘못된 스테이터스
|
||||
### `fs.stat`의 잘못된 스테이터스 정보
|
||||
|
||||
`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 가상의 예측된 정보를 가집니다.
|
||||
`fs.stat` 로 부터 반환되는 `Stats` 객체와 비슷한 API들은 `asar` 아카이브를 타겟으로 할 경우 예측된 디렉터리 피일 정보를 가집니다.
|
||||
왜냐하면 아카이브의 디렉터리 경로는 실제 파일시스템에 존재하지 않기 때문입니다.
|
||||
그러한 이유로 파일 크기와 파일 타입 등을 확인할 때 `Stats` 객체를 신뢰해선 안됩니다.
|
||||
|
||||
## Adding unpacked files in `asar` archive
|
||||
## `asar` 아카이브에 미리 압축 해제된 파일 추가하기
|
||||
|
||||
전술한 바와 같이, 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다.
|
||||
전술한 바와 같이 몇몇 Node API는 호출 시 해당 파일을 임시폴더에 압축을 해제합니다.
|
||||
따로 성능문제가 발생할 수 있습니다. 그리고 백신 소프트웨어의 잘못된 오진을 일으킬 수도 있습니다.
|
||||
|
||||
이 문제를 해결하려면, `--unpack` 옵션을 활용하여 파일을 압축이 풀려진 상태로 유지해야 합니다.
|
||||
이 문제를 해결하려면 `--unpack` 옵션을 활용하여 파일을 압축이 풀려진 상태로 유지해야 합니다.
|
||||
다음의 예제는 node 네이티브 모듈의 공유 라이브러리를 unpack 상태로 유지합니다:
|
||||
|
||||
```bash
|
||||
$ asar pack app app.asar --unpack *.node
|
||||
```
|
||||
|
||||
커맨드를 실행한 후, 같은 디렉터리에 `app.asar` 파일 외에 `app.asar.unpacked` 폴더가 같이 생성됩니다.
|
||||
커맨드를 실행한 후 같은 디렉터리에 `app.asar` 파일 외에 `app.asar.unpacked` 폴더가 같이 생성됩니다.
|
||||
이 폴더안에 unpack 옵션에서 설정한 파일들이 압축이 풀린 상태로 포함되어 있습니다.
|
||||
유저에게 어플리케이션을 배포할 때 반드시 해당 폴더도 같이 배포하여야합니다.
|
||||
|
||||
|
|
|
|||
|
|
@ -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,7 +1,7 @@
|
|||
# 데스크톱 환경 통합
|
||||
# 데스크톱 환경 통합
|
||||
|
||||
어플리케이션을 배포할 서로 다른 운영체제 시스템의 환경과 기능에 맞춰 사용 환경을 통합할 수 있습니다.
|
||||
예를 들어, Windows에선 태스크바의 JumpList에 바로가기를 추가할 수 있고, Mac(OS X)에선 dock menu에 커스텀 메뉴를 추가할 수 있습니다.
|
||||
예를 들어 Windows에선 태스크바의 JumpList에 바로가기를 추가할 수 있고 Mac(OS X)에선 dock menu에 커스텀 메뉴를 추가할 수 있습니다.
|
||||
|
||||
이 가이드는 Electron API를 이용하여 각 운영체제 시스템의 기능을 활용하는 방법을 설명합니다.
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ __어플리케이션 dock menu:__
|
|||
|
||||
<img src="https://cloud.githubusercontent.com/assets/639601/5069610/2aa80758-6e97-11e4-8cfb-c1a414a10774.png" height="353" width="428" >
|
||||
|
||||
파일을 최근 문서에 추가하려면, [app.addRecentDocument][addrecentdocument] API를 사용할 수 있습니다:
|
||||
파일을 최근 문서에 추가하려면 [app.addRecentDocument][addrecentdocument] API를 사용할 수 있습니다:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
|
|
@ -32,15 +32,15 @@ app.clearRecentDocuments();
|
|||
|
||||
### Windows에서 주의할 점
|
||||
|
||||
이 기능을 Windows에서 사용할 땐, 운영체제 시스템에 어플리케이션에서 사용하는 파일 확장자가 등록되어 있어야 합니다.
|
||||
이 기능을 Windows에서 사용할 땐 운영체제 시스템에 어플리케이션에서 사용하는 파일 확장자가 등록되어 있어야 합니다.
|
||||
그렇지 않은 경우 파일을 JumpList에 추가해도 추가되지 않습니다.
|
||||
어플리케이션 등록에 관련된 API의 모든 내용은 [Application Registration][app-registration]에서 찾아볼 수 있습니다.
|
||||
|
||||
유저가 JumpList에서 파일을 클릭할 경우, 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어 새로운 인스턴스의 어플리케이션이 실행됩니다.
|
||||
유저가 JumpList에서 파일을 클릭할 경우 클릭된 파일의 경로가 커맨드 라인 인자로 추가되어 새로운 인스턴스의 어플리케이션이 실행됩니다.
|
||||
|
||||
### OS X에서 주의할 점
|
||||
|
||||
파일이 최근 문서 메뉴에서 요청될 경우, `app` 모듈의 `open-file` 이벤트가 호출됩니다.
|
||||
파일이 최근 문서 메뉴에서 요청될 경우 `app` 모듈의 `open-file` 이벤트가 호출됩니다.
|
||||
|
||||
## 커스텀 독 메뉴 (OS X)
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ __Terminal.app의 dock menu:__
|
|||
|
||||
<img src="https://cloud.githubusercontent.com/assets/639601/5069962/6032658a-6e9c-11e4-9953-aa84006bdfff.png" height="354" width="341" >
|
||||
|
||||
커스텀 dock menu를 설정하려면, `app.dock.setMenu` API를 사용하면 됩니다. OS X에서만 사용 가능합니다:
|
||||
커스텀 dock menu를 설정하려면 `app.dock.setMenu` API를 사용하면 됩니다. OS X에서만 사용 가능합니다:
|
||||
|
||||
```javascript
|
||||
var app = require('app');
|
||||
|
|
@ -74,7 +74,7 @@ MSDN에선 해당 기능을 다음과 같이 설명하고 있습니다:
|
|||
|
||||
> 어플리케이션 작업은 프로그램의 기능 그리고 주요사양 두가지를 기반으로 유저의 행동을 예측하여 정의합니다.
|
||||
> 실행할 필요가 없는 어플리케이션 작업은 작동하지 않을 때 반드시 context-free를 유지해야 합니다.
|
||||
> 작업은 일반 사용자가 프로그램을 실행하거나, 이메일 프로그램으로 이메일을 작성하거나 달력을 불러오고,
|
||||
> 작업은 일반 사용자가 프로그램을 실행하거나 이메일 프로그램으로 이메일을 작성하거나 달력을 불러오고
|
||||
> 워드 프로세서로 새 문서를 작성, 특정 모드, 부속 명령으로 프로그램을 실행하는 등의
|
||||
> 통계적, 일반적으로 가장 많이 사용되는 작업인지를 고려해야 합니다.
|
||||
> 어플리케이션 작업은 일반 유저가 필요로 하지 않는 고급 기능을 조잡하게 채우거나 등록과 같은 일회성의 작업을 포함해선 안됩니다.
|
||||
|
|
@ -82,14 +82,14 @@ MSDN에선 해당 기능을 다음과 같이 설명하고 있습니다:
|
|||
>
|
||||
> 작업 리스트는 가능한 한 정적으로 유지되는 것을 적극 권장합니다.
|
||||
> 이것은 동일한 상태 또는 응용 프로그램의 상태에 관계없이 유지되어야 합니다.
|
||||
> 작업 목록은 동적으로 변경할 수 있지만, 몇몇 유저는 예상하지 못한 작업 목록 변경에 혼동할 수 있다는 점을 고려해야 합니다.
|
||||
> 작업 목록은 동적으로 변경할 수 있지만 몇몇 유저는 예상하지 못한 작업 목록 변경에 혼동할 수 있다는 점을 고려해야 합니다.
|
||||
|
||||
__Internet Explorer의 작업:__
|
||||
|
||||
|
||||
|
||||
OS X의 말 그대로 메뉴로 작동하는 dock menu 와는 달리, Windows의 사용자 작업은 어플리케이션 바로가기처럼 작동합니다.
|
||||
유저가 작업을 클릭할 시, 설정한 인자와 함께 새로운 어플리케이션이 실행됩니다.
|
||||
OS X의 말 그대로 메뉴로 작동하는 dock menu 와는 달리 Windows의 사용자 작업은 어플리케이션 바로가기처럼 작동합니다.
|
||||
유저가 작업을 클릭할 시 설정한 인자와 함께 새로운 어플리케이션이 실행됩니다.
|
||||
|
||||
사용자 작업을 설정하려면 [app.setUserTasks][setusertaskstasks] API를 사용하여 구현할 수 있습니다:
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ app.setUserTasks([
|
|||
]);
|
||||
```
|
||||
|
||||
작업 리스트를 비우려면, 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어 호출하면 됩니다:
|
||||
작업 리스트를 비우려면 간단히 `app.setUserTasks` 메서드의 첫번째 인자에 빈 배열을 넣어 호출하면 됩니다:
|
||||
|
||||
```javascript
|
||||
app.setUserTasks([]);
|
||||
|
|
@ -117,7 +117,7 @@ app.setUserTasks([]);
|
|||
|
||||
## Unity 런처 숏컷 기능 (Linux)
|
||||
|
||||
Unity 환경에선, `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding shortcuts to a launcher][unity-launcher] 가이드를 참고하세요.
|
||||
Unity 환경에선 `.desktop` 파일을 수정함으로써 런처에 새로운 커스텀 엔트리를 추가할 수 있습니다. [Adding shortcuts to a launcher][unity-launcher] 가이드를 참고하세요.
|
||||
|
||||
__Audacious의 런처 숏컷:__
|
||||
|
||||
|
|
@ -147,8 +147,8 @@ window.setProgressBar(0.5);
|
|||
|
||||
## 윈도우 대표 파일 제시 (OS X)
|
||||
|
||||
OS X는 윈도우에서 대표 파일을 설정할 수 있습니다. 쉽게 말해, 타이틀바에서 파일 아이콘을 볼 수 있을 때, 사용자가 Command-Click 또는 Control-Click 할 경우 파일 경로 팝업이 보여집니다.
|
||||
또한 윈도우의 상태도 지정할 수 있습니다. 쉽게 말해, 로드된 문서의 수정여부를 타이틀바 파일 아이콘에 표시할 수 있습니다.
|
||||
OS X는 윈도우에서 대표 파일을 설정할 수 있습니다. 쉽게 말해 타이틀바에서 파일 아이콘을 볼 수 있을 때 사용자가 Command-Click 또는 Control-Click 할 경우 파일 경로 팝업이 보여집니다.
|
||||
또한 윈도우의 상태도 지정할 수 있습니다. 쉽게 말해 로드된 문서의 수정여부를 타이틀바 파일 아이콘에 표시할 수 있습니다.
|
||||
|
||||
__대표 파일 팝업 메뉴:__
|
||||
|
||||
|
|
|
|||
|
|
@ -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를 추가하는데 많은 도움이 됩니다.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ _online-status.html_
|
|||
</html>
|
||||
```
|
||||
|
||||
필요하다면, 이러한 이벤트를 메인 프로세스로 보낼 수도 있습니다.
|
||||
필요한 경우 이 이벤트를 메인 프로세스로 보낼 수도 있습니다.
|
||||
메인 프로세스는 `navigator` 오브젝트를 가지고 있지 않기 때문에 이 이벤트를 직접 사용할 수 없습니다.
|
||||
이는 다음 예제와 같이 electron의 inter-process communication(ipc)유틸리티를 사용하여
|
||||
이벤트를 메인 프로세스로 전달하는 것으로 해결할 수 있습니다.
|
||||
|
|
|
|||
|
|
@ -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,7 +31,7 @@ npm install --save-dev electron-rebuild
|
|||
|
||||
### node-gyp을 이용한 방법
|
||||
|
||||
Node 모듈을 `node-gyp`를 사용하여 Electron을 타겟으로 빌드할 땐, `node-gyp`에 헤더 다운로드 주소와 버전을 알려주어야합니다:
|
||||
Node 모듈을 `node-gyp`를 사용하여 Electron을 타겟으로 빌드할 땐 `node-gyp`에 헤더 다운로드 주소와 버전을 알려주어야합니다:
|
||||
|
||||
```bash
|
||||
$ cd /path-to-module/
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Pepper 플래시 플러그인 사용하기
|
||||
|
||||
필요하다면 Pepper 플래시 플러그인을 사용할 수 있습니다. Electron에서 pepper 플래시 플러그인을 사용하기 위해서는, 따로 pepper 플래시 플러그인의 위치를 지정해 주어야합니다.
|
||||
필요하다면 Pepper 플래시 플러그인을 사용할 수 있습니다. Electron에서 pepper 플래시 플러그인을 사용하기 위해선 따로 pepper 플래시 플러그인의 위치를 지정해 주어야합니다.
|
||||
|
||||
## 플래시 플러그인 준비하기
|
||||
|
||||
|
|
|
|||
|
|
@ -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