From 074785cea106179cb3305637055ab0a009ca74f2 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:52 -0500 Subject: initial commit --- files/pt-br/pacotes/index.html | 164 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 164 insertions(+) create mode 100644 files/pt-br/pacotes/index.html (limited to 'files/pt-br/pacotes') diff --git a/files/pt-br/pacotes/index.html b/files/pt-br/pacotes/index.html new file mode 100644 index 0000000000..36c9967535 --- /dev/null +++ b/files/pt-br/pacotes/index.html @@ -0,0 +1,164 @@ +--- +title: Estruturas de um Pacote de Instalação +slug: Pacotes +translation_of: Archive/Mozilla/Bundles +--- +

Aplicações XULRunner, extensões, e temas Compartilham uma mesma estrutura de arquivos, e em alguns casos o mesmo pacote pode ser usado como uma aplicação XULRunner independente, Por Exemplo, a instalação de uma aplicação ou extensão.

+ +

Estrutura Básica de um Pacote

+ +

A bundle may include any of the following files:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Path from the root of the bundleDescriptionVersion information
/install.rdfExtension/Theme Install Manifest 
/application.iniApplication Launch Manifest 
/bootstrap.jsThe bootstrap script for extensions not requiring a restart (those with <em:bootstrap>true</em:bootstrap> in their install.rdf). Note that other files and directories (e.g. chrome.manifest, components, defaults) in bootstrapped extensions are not processed by a supporting application.(>=2.0)
/chrome.manifestChrome Registration Manifest(>=1.8)
/components/*XPCOM components (*.js, *.dll), and interface files from *.xpt(>=1.7)
/defaults/preferences/*.jsDefault Preferences(>=1.7)
/plugins/*NPAPI Plugins(>=1.8)
/chrome/icons/default/*Window Icons(>=1.8)
/options.xulExtension options, for display in the Add-ons Manager(>=7.0)
...Additional resources (such as chrome:// or resource:// providers can be registered in the chrome.manifest) 
Application-specific
/searchplugins/*.srcSherlock search pluginsFirefox 1.5 and greater.
/searchplugins/*.xmlMozSearch and OpenSearch pluginsFirefox 2 and greater
/dictionaries/*.{aff|dic}Myspell dictionariesFirefox 2 and greater
+ +

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 files

+ +

Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1) removed support for platform-specific subdirectories, described below. Instead, you need to use manifest flags, such as the OS and ABI flags, in your chrome manifest to specify components that should be loaded for specific platforms.

+ +

For example:

+ +
binary-component components/windows/mycomponent.dll ABI=WINNT_x86-msvc
+binary-component components/mac/mycomponent.dylib ABI=Darwin_x86-gcc3
+binary-component components/mac/mycomponent64.dylib ABI=Darwin_x86_64-gcc3
+binary-component components/linux/mycomponent.so ABI=Linux_x86-gcc3
+
+ +

This also means you can no longer have platform-specific preference files in your bundle.

+ +

Platform-specific subdirectories: Gecko 1.9.2.x and earlier

+ +
+

Note: Platform-specific subdirectory support was removed in Gecko 2.0. See the section Platform-specific files to learn how to use platform-specific files.

+
+ +

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(of the form: /platform/Linux*/), Macintosh(of the form: /platform/Darwin*/), and Windows(of the form: /platform/WIN*/), 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.

+ +

Official references for toolkit API

+ +

+

-- cgit v1.2.3-54-g00ecf