Thunderbird-Addons: Grundstruktur

Ich hatte ja gerade angedroht, hier mal ein Thunderbird-Addon genauer unter die Lupe zu nehmen, nämlich Quicker Filer, konkret die gerade aktuelle Version 0.5.1.

Packt man das Archiv quicker_filer-0.5.1-tb.xpi aus (mit unzip), kommen folgende Dateien zum Vorschein:

./chrome.manifest
./content
./content/common.js
./content/options.js
./content/options.xul
./content/messengercomposeoverlay.xul
./content/quickerfilerdialog.xul
./content/quickerfilerdialog.js
./content/messengeroverlay.js
./content/messengercomposeoverlay.js
./content/messengeroverlay.xul
./components
./components/quickerfilerautocomplete.js
./install.rdf

Einen Überblick, wie die Struktur so einer Extension aussehen soll, gibt diese Anleitung. Die Struktur so eines Bundles ist auch nochmal hier erläutert, wobei sich da einiges zu überschneiden scheint.

Ausgangspunkt ist jedenfalls erstmal die install.rdf, also ein Install Manifest. Im vorliegenden Fall sieht das so aus:

[sourcecode language="xml"]
<?xml version="1.0"?>

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:em="http://www.mozilla.org/2004/em-rdf#">

<Description about="urn:mozilla:install-manifest">
<em:id>qfiler@eivind.rovik</em:id>
<em:name>Quicker Filer</em:name>
<em:version>0.5.1</em:version>
<em:description>Quicker Filer [...]</em:description>
<em:creator>Eivind Rovik</em:creator>
<em:type>2</em:type>

<em:optionsURL>chrome://quickerfiler/content/options.xul</em:optionsURL>

<em:targetApplication>
<Description>
<em:id>{3550f703-e582-4d05-9a08-453d09bdfdc6}</em:id>
<em:minVersion>3.0</em:minVersion>
<em:maxVersion>5.*</em:maxVersion>
</Description>
</em:targetApplication>

</Description>
</RDF>
[/sourcecode]

Das “basic layout” stimmt also überein. Gehen wir die Eigenschaften mal der Reihe nach durch, erst die erforderlichen:

  • id: Hier im @-Format angegeben – das ist in der Tat deutlich anschaulicher als GUIDs …
  • version: Auch wenn man daraus durchaus eine Wissenschaft machen kann, ist es in diesem Fall recht einfach: Drei Zahlen, durch Punkte getrennt.
  • type: Hier wird es unintuitiv. “2″ steht für eine Extension – also das, worum es mir gerade auch geht.
  • targetApplication: Was hier zulässige Werte für id sind, ist auf dieser Seite aufgelistet. Thunderbird ist {3550f703-e582-4d05-9a08-453d09bdfdc6}. minVersion und maxVersion sagen aus, mit welchen Thunderbird-Versionen das Addon kompatibel ist, in diesem Fall also alle Versionen von 3.0 bis zu 5.* (das .* spielt mit dem Rapid Release Scheme wohl eh keine Rolle mehr …).
  • name: Der Name des Addons, hier also Quicker Filer.

Außerdem gibt es noch optionale Eigenschaften. Ich gehe jetzt nur auf die ein, die bei Quicker Filer gesetzt sind:

  • description: Eine einzeilige Beschreibung, die im UI (also dem Addon-Manager) angezeigt wird.
  • creator: Der Name des Entwicklers
  • optionsURL: Die chrome-URL eines Einstellungsdialogs für das Addon. Dazu in einem späteren Post mehr.

Schauen wir uns anhand der bereits genannten Seite die restlichen Dateien an:

  • chrome.manifest: Ein sog. Chrome Registration Manifest. Chrome ist alles, was zum UI der eigentlichen Anwendung gehört – bei Thunderbird also alles bis auf die angezeigten Mails, und eventuell auch angezeigte Webseiten. Im Prinzip wird dort der Aufbau des Pakets beschrieben – auf die Details werde ich in einem späteren Posting eingehen.
  • components: In diesem Verzeichnis liegen XPCOM-Komponenten – auch dazu später mehr.
  • content: Der Name dieses Verzeichnisses folgt keiner besonderen Konvention. In dem Verzeichnis liegen Teile des User-Interfaces, diese müssen aber in chrome.manifest registriert werden. Dazu also später mehr.

Damit endet der Überblick über die Struktur eines Addons und damit der erste Teil einer vermutlich längeren Serie von Postings. Zur Sicherheit noch der obligatorische Hinweis: Code-Schnipsel stammen aus Quicker Filer 0.5.1, sind Copyright (C) 2010 Eivind Rovik und stehen unter GPL (Version 3 oder jede spätere Version).

2 thoughts on “Thunderbird-Addons: Grundstruktur

  1. Ja, man sollte sich wohl wegen dem rapid release scheme an maxVersion=* gewöhnen, wenn man nicht ständig (selbst) neu releasen will. Das halte ich für keine gute Idee vom Mozilla Team…

  2. Pingback: Thunderbird-Addons: Chrome-Manifest, XUL-Overlays « tessarakt – das vierdimensionale B-L-O-G

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>