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
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
- Struktur eines installierbaren Bündels: Beschreibung der gemeinsamen Struktur von installierbaren Bündeln von Erweiterungen, Themes und XULRunner Anwendungen
- Packen von Erweiterungen: Informationen über das Packen von Erweiterungen
- Packen von Themes: Informationen über das Packen von Themes
- Packen von mehreren Erweiterungen: Informationen über das Packen von mehreren Erweiterungen
- Packen einer XUL Anwendung: Informationen über das Packen von XUL Anwendungen
- Chrome Registrierung