Struktur eines installierbaren Bündels

von 2 Mitwirkenden:

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

Schlagwörter des Dokuments und Mitwirkende

Schlagwörter: 
Mitwirkende an dieser Seite: fscholz, Ak120
Zuletzt aktualisiert von: fscholz,