Internal Server Error beim MDN

Ich hatte mich über Interpunktionsfehler im Mozilla-Entwicklerhandbuch des Mozilla Developer Networks (MDN) geärgert. Allerdings nur so geringfügig. Aus gutem Grund.

Als ich das kurz in einem IRC-Channel von Mozilla anmerkte, kam die Frage, ob ich schon einen Bug angelegt hätte. Nein, denn: Es hat mich nur geringfügig geändert, und sowas unterbricht immer den Arbeitsfluss. Aber wo schonmal die Frage kam, bin ich es halt doch angegangen.

MDN ist ein Wiki. Ich war mir ziemlich sicher, mich dort schonmal angemeldet zu haben. Ein Passwort war im Firefox aber nicht (mehr) gespeichert. Egal, also anmelden. MDN benutzt inzwischen “Persona”. Das hieß früher mal “BrowserID”, ist aber nicht ansatzweise browserbasiert. Es ist irgendwie eine Alternative zu OpenID und SAML SSO, ohne das einem erklärt wird, warum man sich für Single Sign On nochmal wieder ein Konto anlegen soll. Dort hatte ich mich eigentlich auch schonmal angemeldet. Aber vermutlich war das, als es noch nicht Persona hieß. Also hab ich dort eine E-Mail-Adresse registriert. Mit der bin ich dann zurück zu MDN. Dort sollte ich einen Benutzernamen angeben. “tessarakt” gibt es schon. Aha, habe ich also doch schon ein Konto. Weiter unten konnte man sich dann zuschicken lassen, welche E-Mail-Adresse mit dem Konto verbunden ist. Also angeklickt. Ergebnis:

Persona hilft natürlich auch nicht beim tatsächlichen Verwalten mehrere Identitäten. Es ist nur die zigste Neuimplementierung von etwas, was es schon längst gibt, ohne über die eigentlichen Probleme auch nur nachzudenken.

Jedenfalls war die zuerst angegebene Adresse offenbar nicht die, die zu dem MDN-Konto gehörte. Als ich die zweite bei Persona angab, behauptete die/der/das:

Wir haben gerade eine E-Mail an diese Adresse verschickt! Wenn Sie wirklich noch eine senden möchten, warten Sie ein oder zwei Minuten und versuchen Sie es dann erneut.

Nein, habt ihr nicht. Und einige Minuten später ging es immer noch nicht.

Fazit: Durch diverse Umstellungen lief das ganze natürlich nicht reibungslos “mal eben schnell”. Und bei Mozilla ist man offenbar damit beschäftigt, “lustige” Bildchen zu produzieren, um 500er-Fehler zu illustrieren, als dafür zu sorgen, dass die gar nicht erst auftreten. Mit sowas vertreibt man leicht die Leute, die man eigentlich bräuchte …

Entwicklungs-Mozilla vom Produktiv-Mozilla trennen

(UPDATE unten)

Ich wollte mal wieder einen Mozilla (in diesem Fall: Thunderbird) bauen, um damit ein wenig rumzuspielen.

Im Prinzip ist das relativ unkompliziert. Die entsprechende Seite im MDN findet man allerdings nur, wenn man weiß, dass es so etwas doch wohl geben muss (MDN-Startseite > Themen – Mozilla > über Mozilla Entwickler-Guide ins Entwicklerhandbuch > “Mit dem Mozilla Quellcode arbeiten”. Dort ist dann gleich der erste Link nicht verfügbar. Also auf Englisch umstellen. Unter “Getting the code from the Mercurial repository” findet man die ausführliche Build-Anleitung schonmal nicht. Über “Bugs for Newcomers” bin ich dann hierhin gelangt. Dort ist dann schließlich ein Link auf “Simple Thunderbird build”. Gut strukturiert geht anders.) Wenn man das gefunden hat, kann man den Code auschecken (ich habe comm-beta genommen und den Code dann lokal gleich in ein Git-Repository gepackt) und die Build-Optionen setzen:

Meine .mozconfig sieht so aus:

ac_add_options --enable-debug
mk_add_options MOZ_MAKE_FLAGS="-j4"
ac_add_options --enable-application=mail
ac_add_options --enable-trace-malloc

ac_add_options --enable-calendar

Dann wollte ich aber endlich mal (bzw. mal wieder, ich hatte in die Richtung schonmal recherchiert) das Problem lösen, dass der Development-Build natürlich ein anderes Profilverzeichnis als das produktive ~/.thunderbird nutzen soll, und sich auch problemlos gleichzeitig mit der Produktivversion starten lassen soll. Mozillen sind da leider etwas eigen … Der Channel #maildev auf irc.mozilla.org war leider wenig hilfreich: Ich solle doch einfach ein weiteres Profil (im gleichen Profilverzeichnis) anlegen und mit --no-remote starten. Ja toll, dann muss ich IIRC die Produktivversion aber ebenfalls mit --no-remote starten und das Profil explizit auswählen. Eine kurze Suche brachte zutage, dass bei Debian die Profile unter ~/.mozilla-thunderbird liegen. Also habe ich dort ins Source-Archiv reingeschaut und herausgefunden, dass das Profilverzeichnis normalerweise aus dem Anwendungsnamen ermittelt wird und die entsprechenden Variablen in application.ini gesetzt werden. Ich habe dann einfach in mail/app/application.ini eine Minimal-Änderung vorgenommen:

@@ -4,7 +4,7 @@

#filter substitution
[App]
-Name=Thunderbird
+Name=ThunderbirdDev
Version=@APP_VERSION@
BuildID=@GRE_BUILDID@
#ifdef MOZ_SOURCE_REPO

Am Namen des Executables hat das zwar nichts geändert, und am Fenstertitel auch nicht. Aber der gebaute Thunderbird lässt sich jetzt problemlos gleichzeitig mit dem “normalen” starten und schreibt seine Config nach ~/.thunderbirddev. Die Feinheiten des Build Engineerings sind mir ja ansonsten ziemlich egal.

UPDATE: Die gerade genannten Änderungen haben ab September 2013 plötzlich nicht mehr geholfen. Stattdessen (bzw. zusätzlich) habe ich nun die Einträge in mail/confvars.sh geändert.

Dokumentenablage

Ich denke gerade darüber nach, wie ich meine Dokumentenablage vernünftig organisiere. Zuerst einmal betrifft das die Ablage beispielsweise von Schreiben. Bisher habe ich dafür einen Ordner “korrespondenz”, aber nur auf meinem PC zu Hause. Nun hätte ich sowas aber auch gerne synchronisiert. Ich könnte es mit rsync, unison oder Ähnlichem probieren. Aber dafür muss man dann ja die zu synchronisierenden Rechner manuell abgleichen. Oder gibt es da auch etwas, was das automatisch anstößt, sobald die sich sehen können? Und klappt das auch mit mehr als zwei Rechnern zuverlässig? Das nächste, woran ich dann gedacht habe, ist ein Versionsverwaltungssystem. Allerdings frage ich mich zum Einen, ob das nicht Overkill ist. Und ich müsste dann mal vom altmodischen SVN weg und am Besten Git ausprobieren. Benutzt das jemand für solche Zwecke? Und eine History ist ja praktisch – allerdings könnte sie bei großen Binärdateien eher hinderlich sein. In der Uni ist mir sowas relativ egal, aber wenn ich den Speicherplatz selbst bereitstellen und bezahlen muss … Benutzt jemand SVN oder Git für so einen Zweck? Irgendwelche Idee, was man mit Binärdateien oder generierten Dateien am besten macht? Jedes Mal ein neues PDF einchecken, wenn man ein Komma ergänzt hat, ist ja auch nicht das Wahre … Ebenso bei Formaten wie ODT oder ODS …

Oder wären vielleicht verteilte Dateisysteme eine Alternative? Gibt es da mittlerweile etwas Ordentliches? Als ich vor Jahren mal geschaut hatte, sah das alles ziemlich kompliziert zu konfigurieren aus … Ideal wäre da eine Lösung, die automatisch ein Overlaynetzwerk aufbaut und darüber verschlüsselt kommuniziert.

Und die Sache ist halt, dass für manche Dateien Versionierung nützlich wäre, für andere aber Overkill. Das zu kombinieren, stelle ich mir irgendwie schwierig vor …

Und was damit noch gar nicht gelöst ist, ist die Metadatenverwaltung (Beispiel: Wann wurde ein Brief abgeschickt, worauf ist er eine Antwort, etc.) und Verwaltungsfunktionen wie Wiedervorlage etc.

Ich freue mich über sämtliche Ideen zu diesem Thema …

Bilder mit GPS-Koordinaten versehen

Leider haben Consumer-Kameras ja noch kein GPS (meine Dezember 2009 gekaufte jedenfalls nicht). Aber wenn man ein Outdoor-GPS-Gerät sein eigen nennt, kann man das ja zum Glück recht einfach anderweitig erledigen. So ein Gerät (ich habe ein eTrex Vista HCx von Garmin) läuft mit 2 AA-Batterien ca. 20 Stunden, und man kann es einfach im Rucksack oder der Jackentasche mit sich rumtragen. Dabei zeichnet es jede Sekunde die Position in einer GPX-Datei (eine Datei pro Tag) auf Speicherkarte auf.

Prinzipiell täte es auch ein einfacher GPS-Logger (der dann deutlich kompakter ausfallen könnte), aber das Display ist ganz praktisch. Die Zeit auf der Kamera muss man ja in der Regel manuell einstellen — eine automatische Synchronisation mit GPS oder einer anderen Zeitnormalquelle haben die Dinger nicht. Das könnte man tun, man kann es aber genauso gut lassen. Denn so eine Uhr hat ja auch ein wenig Gangabweichung, beim nächsten Urlaub stimmt es dann schon wieder nicht. Eine Minute Abweichung ist jedenfalls (mir) zuviel, um mich für die GPS-Korrelation darauf zu verlassen.

An dieser Stelle kommt das Display des GPS-Empfängers ins Spiel: Man macht ab und zu (am Anfang und am Ende des Urlaubs beispielsweise …) Fotos von einer als zuverlässig bekannten Uhrzeitanzeige – dafür bietet sich die des GPS-Empfängers an (Beispiele hier und hier). Dann hat man die Kamerazeit (über EXIF-Daten) und die echte Zeit in einem Foto und kann somit die Differenz ermitteln.

Beispiel: Ich hatte zwei Fotos vom GPS-Empfänger gemacht:

  • Auf dem ersten Foto zeigte der GPS-Empfänger 12:04:40 Uhr am 30. Juli 2011 (Europe/Berlin, also MESZ). Nach Ortszeit (in diesem Fall Island, also erfreulicherweise gleichzeitig UTC – es entfällt also die schwierige Entscheidung, welche von beiden ich nehmen soll) ist das 10:04:40 Uhr. Die Zeit der Kamera war 11:06:09 (also vermutlich MEZ, ohne S) am 30. Juli 2010 (sic!). Um von der Kamerazeit auf die richtige Zeit zu kommen, muss man also ein Jahr hinzuzählen, 1 Stunde abziehen, 2 Minuten abziehen und 31 Sekunden hinzuziehen (bzw: 1:29 Minuten abziehen).
  • Auf dem zweiten Foto zeigte der GPS-Empfänger 13:13:10 Uhr am 2. August 2011 (MESZ). Nach Ortszeit/UTC ist das 11:13:10 Uhr. Die Zeit der Kamera war 12:14:38 (MEZ) am 2. August 2010 (sic!). Um von der Kamerazeit auf die richtige Zeit zu kommen, muss man also ein Jahr hinzuzählen, 1 Stunde abziehen, 2 Minuten abziehen und 28 Sekunden hinzuziehen (also 1:28 Minuten, und damit nur eine Sekunde Abweichung zum ersten Foto, die auch Rundungsfehlern geschuldet sein können).

Nachdem wir nun also wissen, wie wir die EXIF-Zeit justieren müssen, können wir diese Änderung umsetzen. Als Tool dafür benutze ich exiv2. Die relevanten Stellen der man-Page lauten:

Benutzung: exiv2 [ Optionen ] [ Aktionen ] Datei ...

Ändert die Exif-Metadaten von Bildern.

Aktionen:
ad | adjust ändert die Exif-Zeitstempel um eine gegebene Zeit. Diese
Aktion benötigt mindestens eine der Optionen -a, -Y, -O oder -D.
[...]

-a time Zeitjustierung im Format [-]HH[:MM[:SS]]. Diese Option wird
nur in Zusammenhang mit der Aktion 'Justieren' benutzt.
-Y yrs Justierung von Jahren in der Aktion "justieren".
-O mon Justierung der Monate in der Aktion 'justieren'.
-D day Jusitierung von tagen in der Aktion "Justierung".

In unserem Fall ergibt das:

exiv2 -Y 1 -a -01:01:28

In diesem Fall ist es herzlich egal, ob man nun -01:01:28 oder -01:01:29 schreibt. Bei größerem Drift sind natürlich ggf. andere Maßnahmen erforderlich. Interpolieren dürfte manuell leider etwas aufwendig werden.

Dieser Befehl muss natürlich auf alle Fotos angewendet werden. Bei mir haben diese die Endung .JPG (nicht .jpg!). Es ergibt sich folgender Befehl:

for i in *.JPG; do exiv2 -Y 1 -a -01:01:28 $i; done

Als nächstes kopiere ich die GPX-Tracks für die entsprechenden Tage ins selbe Verzeichnis wie die Bilder und rufe gpscorrelate-gui auf. Dort füge ich zunächst alle Fotos hinzu. Dort muss man nun leider jede GPX-Datei einzeln auswählen. “Interpolate”, ggf. “Between Segments” ankreuzen, “Correlate Photos” klicken – fertig.

Jetzt haben die Fotos GPS-Koordinaten in ihrem EXIF-Block. Bei Flickr und ähnlichen Diensten erscheinen sie dann in einer Karte (Achtung: Bei Flickr muss man das aus Datenschutzgründen in den Account-Einstellungen vor dem Hochladen aktivieren!).

Thunderbird-Addons: Chrome-Manifest, XUL-Overlays

Und weiter geht es da, wo der letzte Teil aufgehört hat: Was steht eigentlich in diesem Chrome Registration Manifest so drin? Beispiel ist wieder Quicker Filer 0.5.1. Die chrome.manifest sieht dort so aus:

[sourcecode]
content quickerfiler content/

overlay chrome://messenger/content/messenger.xul chrome://quickerfiler/content/messengeroverlay.xul
overlay chrome://messenger/content/messengercompose/messengercompose.xul chrome://quickerfiler/content/messengercomposeoverlay.xul

component {1C28D908-9DD7-11E0-B67F-DCD94724019B} components/quickerfilerautocomplete.js
contract @mozilla.org/autocomplete/search;1?name=quickerfiler-autocomplete {1C28D908-9DD7-11E0-B67F-DCD94724019B}
[/sourcecode]

Der Reihe nach:

  • Die erste Zeile ist ein sog. content package.
    Das erste content ist ein Schlüsselwort. quickerfiler ist der Name des Packages. content/ ist ein URI, der auf den Inhalt des Packages zeigt – in diesem Fall ein relativer Pfad. Diese Registrierung sorgt dafür, dass Chrome-URIs der Form chrome://quickerfiler/content/... (man beachte, dass auch hier content auftaucht!) aufgelöst werden können, also die entsprechenden Dateien gefunden werden.
  • Die zweite und dritte Zeile definieren XUL-Overlays, also Erweiterungen von bestehenden Sichten der Benutzeroberfläche. Vorliegend werden das Hauptfenster (3-pane window) und das Fenster zum Verfassen neuer Mails erweitert – dazu aber später mehr.
  • Schließlich folgen noch die Definition einer Komponente und eines sog. Contracts (also einer Schnittstelle mit einer Implementierung). Mehr über Komponenten im allgemeinen und diese spezielle später.

Kommen wir also zu den XUL-Overlays. content/messengeroverlay.xul sieht wie folgt aus:

[sourcecode language="xml"]
<?xml version="1.0"?>
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<script type="application/x-javascript" src="chrome://quickerfiler/content/messengeroverlay.js"/>
<keyset>
<key id="quickerfiler_key_move" oncommand="sQuickerFilerMessengerOverlay.openDialog(‘move’);" modifiers="alt" key="q" />
<key id="quickerfiler_key_copy" oncommand="sQuickerFilerMessengerOverlay.openDialog(‘copy’);" />
<key id="quickerfiler_key_insmove" oncommand="sQuickerFilerMessengerOverlay.openDialog(‘insmove’);" />
<key id="quickerfiler_key_inscopy" oncommand="sQuickerFilerMessengerOverlay.openDialog(‘inscopy’);" />
<key id="quickerfiler_key_selfolder" oncommand="sQuickerFilerMessengerOverlay.openDialog(‘selfolder’);" modifiers="alt" key="r" />
</keyset>
</window>
[/sourcecode]

Das Ganze ist, wie schon erwähnt, ein Overlay für messenger.xul, das Hauptfenster von Thunderbird. Dieses Hauptfenster ist ziemlich kompliziert und importiert noch diverse andere XUL-Dokumente. Aber zum Glück kommt es darauf nicht wirklich an – das Overlay definiert einfach Aktionen, die mit Tastenkombinationen ausgelöst werden können und legt fest, welche Javascript-Kommandos in dem Fall ausgeführt werden. Die Ergänzung von Kontextmenüs o.ä. wäre vermutlich sehr viel komplizierter …

Die Bedeutung des script-Elements ist ziemlich offensichtlich, genau wie die von keyset und key. Außerdem gibt es noch ein Tutorial zu dem ganzen Thema. Was vielleicht noch interessant ist, dass nur zwei der key-Elemente auch tatsächlich schon eine Tastenkombination festlegen. Das geschieht zur Laufzeit: content/messengeroverlay.js registriert folgenden Event-Handler:

[sourcecode language="javascript"]
window.addEventListener(‘load’, function () { sQuickerFilerMessengerOverlay.onLoad(); }, false);
[/sourcecode]

Dieser Listener wird zum Fenster hinzugefügt also ausgeführt, wenn das Fenster (in diesem Fall also das Hauptfenster von Thunderbird geladen ist. sQuickerFilerMessengerOverlay.onLoad() lädt die Tastenkombinationen aus den Preferences und setzt die entsprechenden Eigenschaften der key-Elemente.

Das andere Overlay ist content/messengercomposeoverlay.xul:

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

<overlay id="sample" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

<script type="application/x-javascript" src="chrome://quickerfiler/content/common.js"/>
<script type="application/x-javascript" src="chrome://quickerfiler/content/messengercomposeoverlay.js"/>

<vbox id="addresses-box">
<toolbox id="quickerfiler.CopyToFolderToolbox">
<hbox align="center">
<label value="Copy message to:" />
<textbox id="quickerfiler.CopyToFolder" flex="1" class="toolbar" disableonsend="true"
type="autocomplete"
autocompletesearch="quickerfiler-autocomplete"
maxrows="14"
tabscrolling="true"
autoFill="true"
forcecomplete="true"
showcommentcolumn="false" />
</hbox>
</toolbox>
</vbox>

</overlay>[/sourcecode]

Dieses Overlay erweitert messengercompose.xul.

Die script-Elemente sind wieder selbsterklärend. Allerdings fällt auf, dass weiter unten keine Javascript-Befehle enthalten sind. Warum wird also überhaupt Code aufgerufen? Nun, content/messengercompose.js enthält folgende Befehle (die beim Laden des Skripts ausgeführt werden):

[sourcecode language="javascript"]
window.addEventListener(‘load’, function () { sQuickerFilerMessengerComposeOverlay.onOpen(); }, false);
window.addEventListener(‘compose-window-reopen’, function () { sQuickerFilerMessengerComposeOverlay.onOpen(); }, true);
window.addEventListener("compose-send-message", function(aEvent) { sQuickerFilerMessengerComposeOverlay.sendEventHandler(aEvent); }, true);
[/sourcecode]

Zur genauen Bedeutung der Events später mehr, wenn ich mir den Code anschaue.

Die taucht bereits im Dokument auf. Das heißt also, das dieses Element vom Overlay erweitert wird – in diesem Fall wird eine toolbox hinzugefügt (unter der Empfängerliste und der Betreffzeile. Warum ausgerechnet eine toolbox, ist mir übrigens nicht klar. Laut Dokumentation dienen diese als Container für toolbars – eine solche taucht hier aber nicht auf (ah, halt: Die Textbox unten hat class="toolbar" – vielleicht hat das ja etwas zu bedeuten). Darin ist dann eine hbox, ein einfacher Container, der der Gruppierung dient. Das label ist ebenfalls uninteressant (außer vielleicht für die Frage, wie das Ganze layouttechnisch funktioniert – dazu vielleicht ein anderes Mal mehr).

Das Spannende ist dagegen die textbox. Gehen wir einfach die Attribute einzeln durch:

  • flex: Dieses Attribut legt fest, wie freier Platz zwischen Elementen verschoben wird. In diesem Fall geht also sämtlicher freier Platz an diese Textbox.
  • class: Dieses Element wird in Stylesheets benutzt. Das deutet darauf hin, dass die Verwendung des toolbox-Elements auch nur layouttechnische Gründe hat.
  • disableonsend: Hier fehlt auf MDN Dokumentation, siehe Mozilla-Bug 670512.
  • type: Gibt den Typ der textbox an, wenn es nicht nur ein simples Textfeld sein soll. In diesem Fall, autocomplete, ist die Sache so kompliziert, dass es gesonderte Dokumentation dazu gibt. Die folgenden Attribute sind alle spezifisch für autocomplete. Im Zusammenhang ist das wohl Thema für einen eigenen Artikel …
  • autocompletesearch: Gibt an, wo die Vorschläge für die Autocompletion herkommen, in diesem Fall von einer speziellen Komponente statt von einer der vordefinierten
  • maxrows: Wie viele Vorschläge werden auf einmal angezeigt, also wie hoch ist das “Menü” höchstens?
  • tabscrolling: In diesem Fall iteriert man mit Tab durch die Vorschläge, anstatt zum nächsten Element zu gehen.
  • autoFill: Es findet automatische Vervollständigung während des Tippens statt.
  • forcecomplete: Wenn man zu einem anderen Element geht, wird die Eingabe zwangsweise zu einem Vorschlag vervollständigt. Das heißt aber offenbar nicht, dass es nicht möglich ist, auch anderen Text einzugeben als einen der Vorschläge.
  • showcommentcolumn: Es werden zu den Vorschlägen keine weiteren Kommentare angezeigt.

Außerdem gibt es noch zwei eigenständige XUL-Dialoge, options.xul und quickerfilerdialog.xul. Auf die werde ich eingehen, wenn ich alles andere durchhabe und dort noch interessante neue Dinge finde. Als nächstes sind erstmal der Javascript-Code der bisher vorgestellten Funktionalität sowie die Komponente für die Autovervollständigung dran. Es wird also unter anderem um XPCOM gehen.

Wieder 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).

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).

Mail-Ordner suchen

Wenn man eine große und stark verschachtelte Hierarchie von Mail-Ordnern hat, ist es nicht trivial, im Thunderbird gezielt einen davon aufzurufen oder eine Mail dorthin zu verschieben. Dieses Problem hatte ich schon vor ca. zweieinhalb Jahren und habe daraufhin damals Mozilla-Bug 479767 angelegt. Es gab ein paar andere Bugs, die das gleiche forderten, aber ansonsten passierte nichts.

… bis ich vor kurzem das Addon Quicker Filer fand. Die Beschreibung las sich gut, aber es funktionierte noch nicht mit Thunderbird 5. Eine Anfrage beim Programmierer (Eivind Rovik) löste dieses Problem aber nach wenigen Tagen. Meine Produktivität beim Wegsortieren von Mails hat das Addon tatsächlich extrem gesteigert. Leider verhindert unter Linux irgendein Problem noch, dass das simple Auswählen eines Ordner klappt. Eivind Rovik geht davon aus, dass es irgendetwas mit Ordnernamen im hiesigen Profil zu tun haben könnte (und eher nichts mit Windows vs. Linux).

Ich habe mir auch mal den Source-Code des Addons angeschaut. Es ist kompliziert genug, um diverse verschiedene Technologien zu benutzen, aber klein genug, um halbwegs überschaubar zu sein. Ich denke, ich werde es in der nächsten Zeit mal ein bisschen sezieren und die Ergebnisse hier beschreiben. Vielleicht finde ich dabei ja auch den Fehler.