Bundles

  • 리비전 슬러그: Bundles
  • 리비전 제목: Bundles
  • 리비전 아이디: 198501
  • 제작일시:
  • 만든이: 애들아빠
  • 현재 리비전인가요? 아니오
  • 댓글

리비전 내용

title-override Structure of an Installable Bundle /title-override 이 부분은 에러가 나서 리마킹한 부분임. 나중에 새로 고칠 필요가 있음.

현재 번역중입니다.

XULRunner 어플리케이션이나, 확장 기능, and 테마 등과 같은 것들은 공통의 디렉토리 구조를 공유합니다. 경우에 따라서는 같은 번들이 독립적인 XULRunner 어플리케이션으로 쓰임과 동시에 설치 가능한 확장 기능으로 사용될 수도 있습니다. 번들의 기본 구조에는 다음과 같은 파일들이 포함될 수 있습니다

/install.rdf                        Extension/Theme Install Manifest
/application.ini                    Application Launch Manifest
/components/*                       Component and XPT Files      (>=1.7)
/defaults/preferences/*.js          Default Preferences          (>=1.7)
/plugins/*                          NPAPI Plugins                (>=1.8)
/chrome.manifest                    Chrome Registration Manifest (>=1.8)
/chrome/icons/default/*             Window Icons                 (>=1.8)

Of course, an extension need not (and normally won't) have all of these directories. Themes are limited for security reasons, and can normally only provide a chrome.manifest which registers the theme and a JAR file.


Platform-specific Subdirectories

In some cases a single extension or application may wish to include binary component or plugins for multiple platforms, or theme authors might want to include multiple platform-specific JAR files. To facilitate the first case, the extension/app loader has special sub-directories specifically for platform-specific files (starting with Toolkit/Gecko 1.8, Firefox/Thunderbird 1.5). The platform string is defined during the toolkit build process to a value unique for the combination of operating system, processor architecture and compiler. The format of the platform string is:

{OS_TARGET}_{TARGET_XPCOM_ABI}

All of the files which are loaded from the main extension directory are loaded from the subdirectory

/platform/{platform string}

if it exists. For example, if a plugin vendor wanted to make a plugin available for consumer computers running Linux, Macintosh, and Windows, it would provide the following files:

/platform/Linux_x86-gcc3/plugins/libMyPlugin.so
/platform/WINNT_x86-msvc/plugins/MyPlugin.dll
/platform/Darwin_ppc-gcc3/plugins/libMyPlugin.dylib

Because XPT files are not platform-specific, any associated XPT files would go in the generic components directory:

/components/MyPlugin.xpt

If an extension has non-binary platform-specific code (such as code which uses the windows registry from script), it can also use just the operating system identifier as a platform-subdirectory:

/platform/WINNT/components/registerDoctype.js

When platform-specific JAR files are used, each platform directory should have its own chrome.manifest file:

chrome.manifest
chrome/mytheme-base.jar
platform/Darwin/chrome.manifest
platform/Darwin/chrome/mytheme-mac.jar
platform/WINNT/chrome.manifest
platform/WINNT/chrome/mytheme-win.jar

The app/extension loader processes the base directory first, followed by the applicable platform directories (first /{OS_TARGET}/, then /{OS_TARGET}_{TARGET_XPCOM_ABI}/). When default preferences are defined in several directories, the ones loaded later overwrite the earlier ones.

Application-specific Extension Files

In addition to the extension files listed above, applications may read additional files from extensions. For example, Firefox 1.5 and greater will read Sherlock search plugins from

/searchplugins/*.src

Firefox 2 and greater will additionally read MozSearch and OpenSearch plugins from

/searchplugins/*.xml

and Myspell dictionaries from

/dictionaries/*.{aff|dic}

Official References for Toolkit API

{{wiki.template(':ko/Toolkit_API/Official_References')}}

{{ wiki.languages( { "fr": "fr/Bundles" } ) }}

리비전 소스

<p><span class="comment">title-override Structure of an Installable Bundle /title-override 이 부분은 에러가 나서 리마킹한 부분임. 나중에 새로 고칠 필요가 있음.</span>
</p><p>현재 번역중입니다. 
</p><p><a href="ko/XUL_Application_Packaging">XULRunner 어플리케이션</a>이나, <a href="ko/Extensions">확장 기능</a>, and <a href="ko/Themes">테마</a> 등과 같은 것들은 공통의 디렉토리 구조를 공유합니다. 경우에 따라서는 같은 번들이 독립적인 XULRunner 어플리케이션으로 쓰임과 동시에 설치 가능한 확장 기능으로 사용될 수도 있습니다. 번들의 기본 구조에는 다음과 같은 파일들이 포함될 수 있습니다 
</p>
<pre class="eval">/<a href="ko/Install.rdf">install.rdf</a>                        <i>Extension/Theme Install Manifest</i>
/<a href="ko/XUL_Application_Packaging">application.ini</a>                    <i>Application Launch Manifest</i>
/components/*                       <i>Component and XPT Files</i>      (&gt;=1.7)
<a href="ko/Building_an_Extension#Defaults_Files">/defaults/preferences/*.js</a>          <i>Default Preferences</i>          (&gt;=1.7)
/plugins/*                          <i>NPAPI Plugins</i>                (&gt;=1.8)
/<a href="ko/Chrome.manifest">chrome.manifest</a>                    <i>Chrome Registration Manifest</i> (&gt;=1.8)
/<a href="ko/Window_icons">chrome/icons/default/*</a>             <i>Window Icons</i>                 (&gt;=1.8)
</pre>
<p>Of course, an extension need not (and normally won't) have all of these directories. Themes are limited for security reasons, and can normally only provide a <a href="ko/Chrome.manifest">chrome.manifest</a> which registers the theme and a JAR file.
</p><p><br>
</p>
<h3 name="Platform-specific_Subdirectories"> Platform-specific Subdirectories </h3>
<p>In some cases a single extension or application may wish to include binary component or plugins for multiple platforms, or theme authors might want to include multiple platform-specific JAR files. To facilitate the first case, the extension/app loader has special sub-directories specifically for platform-specific files (starting with Toolkit/Gecko 1.8, Firefox/Thunderbird 1.5). The platform string is defined during the toolkit build process to a value unique for the combination of operating system, processor architecture and compiler. The format of the platform string is:
</p>
<pre class="eval"><i>{OS_TARGET}</i>_<i>{<a href="ko/XPCOM_ABI">TARGET_XPCOM_ABI</a>}</i>
</pre>
<p>All of the files which are loaded from the main extension directory are loaded from the subdirectory
</p>
<pre class="eval">/platform/<i>{platform string}</i>
</pre>
<p>if it exists. For example, if a plugin vendor wanted to make a plugin available for consumer computers running Linux, Macintosh, and Windows, it would provide the following files:
</p>
<pre class="eval">/platform/Linux_x86-gcc3/plugins/libMyPlugin.so
/platform/WINNT_x86-msvc/plugins/MyPlugin.dll
/platform/Darwin_ppc-gcc3/plugins/libMyPlugin.dylib
</pre>
<p>Because XPT files are not platform-specific, any associated XPT files would go in the generic components directory:
</p>
<pre class="eval">/components/MyPlugin.xpt
</pre>
<p>If an extension has non-binary platform-specific code (such as code which uses the windows registry from script), it can also use just the operating system identifier as a platform-subdirectory:
</p>
<pre class="eval">/platform/WINNT/components/registerDoctype.js
</pre>
<p>When platform-specific JAR files are used, each platform directory should have its own <code>chrome.manifest</code> file:
</p>
<pre class="eval">chrome.manifest
chrome/mytheme-base.jar
platform/Darwin/chrome.manifest
platform/Darwin/chrome/mytheme-mac.jar
platform/WINNT/chrome.manifest
platform/WINNT/chrome/mytheme-win.jar
</pre>
<p>The app/extension loader processes the base directory first, followed by the applicable platform directories (first /{OS_TARGET}/, then /{OS_TARGET}_{<a href="ko/XPCOM_ABI">TARGET_XPCOM_ABI</a>}/). When default preferences are defined in several directories, the ones loaded later overwrite the earlier ones.
</p>
<h3 name="Application-specific_Extension_Files"> Application-specific Extension Files </h3>
<p>In addition to the extension files listed above, applications may read additional files from extensions. For example, <a href="ko/Firefox_1.5">Firefox 1.5</a> and greater will read Sherlock search plugins from
</p>
<pre class="eval">/searchplugins/*.src
</pre>
<p><a href="ko/Firefox_2">Firefox 2</a> and greater will additionally read <a href="ko/Creating_MozSearch_plugins">MozSearch and OpenSearch plugins</a> from
</p>
<pre class="eval">/searchplugins/*.xml
</pre>
<p>and Myspell dictionaries from
</p>
<pre class="eval">/dictionaries/*.{aff|dic}
</pre>
<h3 name="Official_References_for_Toolkit_API"> Official References for <a href="ko/Toolkit_API">Toolkit API</a> </h3>
<p>{{wiki.template(':ko/Toolkit_API/Official_References')}}
</p>{{ wiki.languages( { "fr": "fr/Bundles" } ) }}
Revert to this revision