This is an archived page. It's not actively maintained.

Struktur eines installierbaren Bündels

XULRunner Anwendungen, Erweiterungen, und Themes teilen sich eine gemeinsame Verzeichnisstruktur, und in einigen Fällen kann das gleiche Bündel als eigenständige XULRunner-Anwendung und als eine installierbare Anwendungserweiterung genutzt werden. Die Grundstruktur von Bündeln kann einige der folgenden Dateien beinhalten:

/install.rdf                        Erweiterung/Theme Installationsmanifest
/application.ini                    Anwendungsstartmanifest
/components/*                       Komponenten und XPT Dateien    (>=1.7)
/defaults/preferences/*.js          Voreinstellungen               (>=1.7)
/plugins/*                          NPAPI Plugins                  (>=1.8)
/chrome.manifest                    Chrome-Registrierungsmanifest  (>=1.8)
/chrome/icons/default/*             Fenstersymbole                 (>=1.8)

Natürlich benötigt eine Erweiterung nicht all diese Verzeichnisse. Themes sind aus Sicherheitsgründen eingeschränkt, und können normalerweise nur ein chrome.manifest zur Registrierung und eine JAR-Datei mitliefern.

 

Plattformspezifische Unterverzeichnisse in Gecko 1.9.2 und früher

Hinweis zu Gecko 2.0
(Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1)

Plattformspezifische Unterverzeichnisse wurden mit Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1) entfernt. Siehe Plattform-spezifische Dateien für weitere Informationen.

In einigen Fällen kann eine Erweiterung oder Anwendung es erforderlich machen, eine binäre Komponente oder Plugins für verschiedene Plattformen bereitzustellen, oder Theme-Autoren können mehrere plattformspezifische JAR-Dateien bündeln. Um das zu bewerkstelligen, nutzt der Erweiterungslader besondere Unterverzeichnisse für plattformspezifische Dateien (angefangen ab Toolkit/Gecko 1.8, Firefox/Thunderbird 1.5). Die Plattform-Zeichenkette wird während des Toolkit Build Vorgangs auf einen eindeutigen Wert festgelegt - eine Kombination aus Betriebssystem, Prozessorarchitektur und Compiler. Das Format der Plattform-Zeichenkette ist:

{OS_TARGET}_{TARGET_XPCOM_ABI}

Jede der Dateien, welche vom Erweiterungshauptverzeichnis geladen werden nun vom Unterverzeichnis geladen, wenn es existiert:

/platform/{Plattform Zeichenkette}

Wenn zum Beispiel ein Dritt-Anbieter ein Plugin für Computer unter Linux, Macintosh und Windows bereitstellen möchte, wären folgende Dateien nötig:

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

Weil XPT-Dateien nicht plattformspezifisch sind, landen zugehörige XPT-Dateien in einem generischen Komponentenverzeichnis:

/components/MyPlugin.xpt

Wenn eine Erweiterung nicht-binären, plattformspezifischen Code (z.B. zur Eintragung in die Windows-Registrierung) beinhaltet, kann einfach der Betriebssystem-Bezeichner als Plattform-Unterverzeichnis dienen:

/platform/WINNT/components/registerDoctype.js

Wenn plattformspezifische JAR-Dateien genutzt werden, sollte jedes Plattformverzeichnis eine eigene chrome.manifest Datei enthalten:

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

Der Ladevorgang verarbeitet zuerst das Basisverzeichnis, gefolgt durch die jeweiligen Plattformverzeichnisse (zuerst /{OS_TARGET}/, dann /{OS_TARGET}_{TARGET_XPCOM_ABI}/). Wenn Voreinstellungen in unterschiedlichen Verzeichnissen gesetzt werden, wird das zuletzt geladene das vorherige überschreiben.

Plattform-spezifische Dateien

Mit Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1) wurde die Unterstützung für Plattform-spezifische Unterverzeichnisse entfernt. Stattdessen müssen nun Manifest-Flags, wie zum Beispiel OS und ABI Flags, im Chrome-Manifest verwendet werden, um Komponenten festzulegen, die von bestimmten Plattformen geladen werden sollen.

Zum Beispiel:

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

Anwendungsspezifische Erweiterungsdateien

Zusätzlich zu den oben aufgeführten Erweiterungsdateien, können Anwendungen weitere Dateien aus den Erweiterungen lesen. Firefox 1.5 oder höher liest zum Beispiel Sherlock Suchplugins aus.

/searchplugins/*.src

Firefox 2 und höher werden auch MozSearch und OpenSearch Plugins aus

/searchplugins/*.xml

und Myspell-Wörterbücher aus

/dictionaries/*.{aff|dic}

lesen können.

Offizielle Toolkit API Referenzen