Custom Calendar Defaults 1.4

Die Erweiterung „Custom Calendar Defaults“ hat ein Update auf Version 1.4 erhalten, um mit dem kürzlich veröffentlichten Lightning 3.3 Schritt halten (also funktionieren) zu können.
So mussten einige Änderungen an für meine Erweiterung relevanten Funktionen übertragen werden, die sich mit

ergeben haben. Für die „Zeit anzeigen als“-Funktion wird nun bei ’normalen‘ und bei ganztägigen Terminen auf ‚versteckte‘ Einstellungen zurückgegriffen, die Lightning von Haus aus mitbringt. Insgesamt sollte so alles wie gewohnt funktionieren, mit der Ausnahme, dass es nicht mehr möglich ist, für einen Termin keine Frei/Verfügbar-Information anzugeben (vgl. Bug 998281).

Aufgaben für die Zukunft:

  • Formulierungen „Zeit als“ vs. „Zeit anzeigen als“ vereinheitlichen, sobald das bei Lightning der Fall ist;
  • Umstieg auf Preferences.jsm prüfen;
  • striktere Handhabung der Versionsangaben in der install.rdf prüfen; aktuell scheinen sich beliebige Versionen der Erweiterung in beliebigen ‚Wirten‘ installieren zu lassen;
  • Möglichkeit suchen, von früheren Versionen der Erweiterung angelegten und nun nicht mehr genutzten Prefs wieder zu entfernen.

Fehlermeldungen und Verbesserungsvorschläge sind wie immer willkommen, wegen der Ferienzeit ist eine zeitnahe Reaktion aber selbstverständlich noch weniger zu erwarten als sonst. 🙂

Custom Calendar Defaults 1.4:

Kompatibel mit:
Lightning 3.3 mit Thunderbird 31
Lightning 3.3 mit SeaMonkey 2.28

Die Datei:
CustomCalendarDefaults-1.4-sm+tb.xpi

Die .diff:
1.3_vs_1.4.diff

Custom Calendar Defaults 1.3

Vor einigen Tagen habe ich der Erweiterung „Custom Calendar Defaults“ ein Update auf Version 1.3 verpasst.
Eigentlich dachte ich nach einem Hinweis, dass ich einen dicken Fehler beheben müsste. Tatsächlich stellte sich aber heraus, dass Lightning gut versteckt eine Einstellung bietet, die mir einfach noch nie aufgefallen war: Mit Bug 430805 wurde vor Jahren die Möglichkeit eingeführt, einen Default-Frei/Verfügbar-Status für ganztägige Termine zu definieren – allerdings nur mit Hilfe der erweiterten Konfiguration, nicht per Einstellungen-Dialog. Meine kleine Erweiterung hatte darauf bisher keinerlei Rücksicht genommen, sodass es zu verwirrenden Ergebnissen bei der Terminerstellung kommen konnte. Nun habe ich der Erweiterung die Option hinzugefügt, bequem auf besagte ‚versteckte‘ Lightning-Einstellung zuzugreifen, auf dass sich jeder noch leichter seine Standardeinstellungen zurechtschustern kann.ccd-allday-freebusy
Für alles nach Lightning 3.1 werden wir dann auch schon wieder eine neues Update benötigen, denn an den für Custom Calendar Defaults relevanten Lightning-Funktionen hat es zwischenzeitlich erneut Änderungen gegeben, die übernommen werden müssen.

Aber vorerst:

Custom Calendar Defaults 1.3:

Kompatibel mit:
Lightning 2.6-3.1 mit Thunderbird 24-29
Lightning 2.6-3.1 mit SeaMonkey 2.21-2.26

Die Datei:
CustomCalendarDefaults-1.3-sm+tb.xpi

Die .diff:
1.2_vs_1.3.diff

Lightning lernt Lesen

Lightning wird um ein neues Feature reicher:
Künftig soll es möglich sein, Termininformationen in E-Mail-Texten automatisch zu erkennen, um das Erstellen von Kalendereinträgen erheblich zu vereinfachen. Wenn in einer Nachricht also von einem dreistündigen Treffen ab 16 Uhr die Rede ist und man das im Kalender eintragen möchte, soll der Termindialog entsprechend vor-ausgefüllt sein.

Wer Lightning ab Version 2.6 benutzt, kann das sofort ausprobieren. Ergänzend wird lediglich die Erweiterung Event-extract benötigt, um die entsprechenden Schaltflächen sichtbar zu machen (Rechtsklick > ‚Anpassen‘):

eventextract__toolbar

Dann funktioniert z.B. Folgendes:

eventextract__01eventextract__02eventextract__03eventextract__04eventextract__05eventextract__06eventextract__07eventextract__08eventextract__09eventextract__10

Die Bilder zeigen ausgewählte (aber längst nicht alle) Formulierungsbeispiele, deren Termininformationen erfolgreich ausgelesen werden („Wir treffen uns morgen gegen 17:30 Uhr bis 20 Uhr.“ | „Wir treffen uns am 13. November um 17 Uhr.“ | „Wir treffen uns von Montag bis Mittwoch.“ | „Wir treffen uns morgen ab 18 Uhr. Der Termin dauert drei Tage.“ | „Der Termin beginnt am 20.12.2013 um 12 Uhr. Er endet gegen 14:30 Uhr.“). Zur Unterstützung kann man auch Text in einer Mail markieren, sodass dann nur dieser Text beim Verarbeiten berücksichtigt wird – das kann die Trefferquote in längeren Mails erhöhen.

Lightning macht also Fortschritte beim Lesenlernen – die ‚Gymnasialempfehlung‘ steht allerdings noch aus: „Lightning lernt Lesen“ weiterlesen

Tschüss, Sunbird!

sunbird-logo-rOha – es ist mittlerweile ja wirklich als einfach nur logisch anzusehen, aber trotzdem ist diese comm-central-Änderung in meinen Augen etwas Besonderes:
Die in früheren Zeiten von Mozilla entwickelte Kalenderanwendung Sunbird dürfte fortan wirklich Geschichte sein. Das Gros des Codes ist aus den Quellen genommen worden, nach den Revisionen 170e76bf0acb (comm–central) und d87eaee61930 (mozilla-central) war’s das.

Zugegebenermaßen war es für Laien zuletzt ohnehin nicht mehr ohne Weiteres möglich, aus besagtem Code brauchbare Sunbird-Pakete zu kompilieren, jedenfalls nicht unter Windows – ein Stopp der aktiven Entwicklung mit all den  plausiblen Argumenten, die dazu geführt haben, macht sich natürlich früher oder später bemerkbar. Wenn ich aber daran denke, wie rund um Sunbird 0.2 vor Jahren die ganze Mozilla-Geschichte für mich ihren Anfang nahm, ist das Ende dieses eigenständigen Kalenderprogramms nach wie vor einfach schade.
Im alltäglichen Arbeiten fehlt dennoch nichts: Die Kombination von Thunderbird + Lightning funktioniert seit Langem zuverlässig und komfortabel.

Vermutlich wird es nun Zeit, weitere Inhalte von sunbird-kalender.de z.B. nach thunderbird-mail.de zu migrieren.

Sunbird® und das Sunbird logo® sind eingetragene Markenzeichen der Mozilla Foundation.

„Custom Calendar Defaults“ im August 2012

Heute habe ich der Erweiterung „Custom Calendar Defaults“ eine kleine Aktualisierung verpasst, da ich kürzlich im Austausch mit einem Nutzer darauf gestoßen bin, dass die Homepage-Url ja gar nicht korrekt ist und in ein 404 führt – dies sollte nun behoben sein. Außerdem habe ich (analog zu Veränderungen in den Thunderbird-, Firefox- und Lightning-Repositories vor wenigen Wochen) die Lizenz-Header geändert und die Dateien unter die Mozilla Public License 2.0 gestellt. Ist übersichtlicher. Neben ein paar Versionsnummern-Anpassungen war’s das dann.

Custom Calendar Defaults 1.1:

Kompatibel mit:
Lightning 1.2-1.7 mit Thunderbird 10-15
Lightning 1.2-1.7 mit SeaMonkey 2.7-2.12

Die Datei:
CustomCalendarDefaults-1.1-sm+tb.xpi

Die .diff:
1.0_vs_1.1.diff

Lightning 1.7b3 freigegeben – testen!

Heute wurde Lightning 1.7b3 vom Mozilla Kalenderprojekt zum Testen freigegeben. Ein paar Hinweise zum Prüfen der u.a. in deutscher Sprache vorliegenden Pakete kann man auch in einem Blog-Beitrag des deutschen Übersetzungsprojekts finden.

Obwohl ich mir durchaus wünschen würde, eine klarere Linie bei der Entwicklung von Lightning erkennen zu können (Prioritätensetzung, nächste Ziele usw.), bin ich grundsätzlich sehr zufrieden damit, wie Lightning sich von Version zu Version entwickelt – zumal die Entwicklungsarbeit nach wie vor auf sehr wenigen Schultern lastet (auch wenn Entwickler Philipp zuletzt ein paar längerfristigere Unterstützer gefunden zu haben scheint). Ich erlebe die Anwendung als wieder zunehmend flotter und in Verwendung von einer handvoll CalDAV-Kalendern als zuverlässig und stabil. Danke an’s Entwicklerteam!! Wenn es jetzt doch nur endlich eine vernünftige App gäbe, um auch Aufgaben per CalDAV mit Android zu synchronisieren…

Was mir seit Längerem nicht gefällt, ist kein Manko des Kalenders, sondern eines von Thunderbird. Die oberhalb der Menüleiste angeordneten Tabs finde ich (wie manch anderer ja auch) so unglaublich hässlich und deplatziert, dass ich mir kaum vorstellen kann, mich damit jemals wirklich anzufreunden. Nun ja, UI-Gurus und ihre Suche nach Neuem…

Eine andere vermeintliche Schwäche im UI, über die ich vorhin gestolpert bin, ist dafür glücklicherweise doch keine. In einem frischen Profil sah Thundebird 15 Beta mit Lightning 1.7b3 zunächst so aus:

Der Chat-Button in der Symbolleiste wirkt erst einmal inkonsistent, weil die neue Chat-Funktion ja wie Kalender und Aufgaben auch ihr eigenes Tab bekommt. Aber siehe da, der Schalter lässt sich problemlos besser ablegen:

Man kann auch den umgekehrten Weg gehen und Kalender- wie Aufgaben-Button zusätzlich in der normalen Symbolleiste ablegen – allerdings wird das erst ab Lightning 1.8 anständig aussehen, denn noch sind hier keine monochromen Icons vorhanden:

Aber das sind ohnehin Peanuts. Widmen wir uns lieber mal dem Stresstest der Druckfunktionen!

Eigener Kalenderserver mit ownCloud

Seit Jahren bin ich immer wieder auf der Suche nach der perfekten Lösung, um Kalenderdaten zentral ablegen (all-inkl.com) und über verschiedene Rechner (Sunbird/Lightning) und das Smartphone (CalDAV-Sync beta) verwalten zu können. Seit einigen Wochen zeigt eine out-of-the-box funktionierende Installation von ownCloud nun, dass ich die Suche offenbar beenden kann.

Nach dem Hochladen der Dateien auf den Server kann man fast schon loslegen, es muss nur noch ein kurzer Einrichtungsassistent im Browser durchlaufen werden. Keine Datenbankeinrichtung, keine komplizierten Rewrite-Rules, keine Bastellösungen – im Anschluss an den Assistenten konnte ich meinen Kalender sofort über das CalDAV-Protokoll in meine Sunbird- und Lightning-Installationen sowie in Android einbinden. In Sunbird/Lightning geht das so:

Neuer Kalender > Im Netzwerk > CalDAV > Adresse: http://servername/pfad-zu-owncloud/remote.php/caldav/calendars/benutzername/kalendername

Der Kalendername direkt nach der Installation wäre „default%20calendar“, über den Webseitenzugriff lassen sich aber auch andere Kalender mit weniger komplizierten Namen einrichten.

Das Arbeiten mit dem Kalender geht zügig vonstatten. Verwaltet werden können Termine und Aufgaben, auch Kategorien werden unterstützt. Insgesamt ist das gegenwärtig ein Plus z.B. gegenüber Tine 2.0, einer anderen Lösung für den eigenen Server (etwas umständliche Einrichtung, langsameres Arbeiten, noch keine Aufgabenverwaltung per CalDAV), aber auch gegenüber dem Google Kalender (keine Aufgabenverwaltung per CalDAV in Sunbird/Lightning, noch mehr Daten auf Google-Servern).

Gute Sache!

l10n-merge verwenden

Meistens ist es der Spieltrieb, machmal sind es Sachzwänge wie Bug 756116, gelegentlich Testzwecke – immer wieder ist die Versuchung groß, Kalenderpakete von Sunbird und Lightning selbst zu kompilieren – und zwar bitte schön mit deutschsprachiger Oberfläche, dafür machen wir den Übersetzungskram schließlich.

Einer der zahlreichen möglichen Stolpersteine bei diesem Vorhaben sind die unterschiedlichen Übersetzungsgewohnheiten innerhalb des de-Teams. Denn mit den unterschiedlichen Repositories im Rahmen des RapidRelease-Schemas kann für jedes Produkt aus der Mozilla-Familie an unterschiedlichen Stellen mit der Übersetzung angesetzt werden: Kümmert man sich mit l10n-central auch um die früheste Entwicklung? Oder mit dem  Aurora-Kanal um etwas stabilere Entwicklungsergebnisse? Oder mit dem Beta-Kanal um solche, die es nicht mehr weit bis zur Veröffentlichung haben?  Während der vergleichsweise kleine /calendar/-Zweig meist schon für die ‚central-Familie‘ übersetzt ist, wird die meiste andere Übersetzungsarbeit erst auf dem Aurora-Kanal geleistet. Für die letztendlich veröffentlichten stabilen Versionen ist das völlig egal, für die oben erwähnten Kompilier-Verlockungen allerdings nicht: Wenn z.B. die Thunderbird-Übersetzung auf l10n-central nicht komplett ist, kann von diesem Zweig in aller Regel auch kein deutschsprachiges Lightningpaket gebaut werden, weil der Vorgang dann irgendwann mit Fehlern wegen vermisster Dateien oder Einträge abbricht.

Damit genau das nicht passiert, wurde das Werkzeug l10n-merge erstellt und für diverse Build-Setups von Mozilla-Servern aktiviert. Es ist Teil von compare-locales, einem Script, mit dem man v.a. die Vollständigkeit einer Übersetzung prüfen kann. Mit l10n-merge lassen sich dann fehlende Übersetzungsteile durch englische Pendants ersetzen. Das war doch genau das, was ich zum Bauen deutschsprachiger Thunderbird-/Lightningpakete von comm-central/l10n-central gesucht habe!! Leider ist die Verwendung von l10n-merge nicht so richtig gut dokumentiert oder ich habe die wertvollsten Quellen einfach nicht gefunden – jedenfalls ließ sich die Chose nicht sofort fehlerfrei einrichten. Trotz l10n-merge brach das Kompilieren immer noch wegen fehlender Übersetzungsdateien ab!

Der Clou scheint zu sein, dass l10n-merge zwar fehlende Einheiten innerhalb vorhandener Übersetzungsdateien ergänzt, aber keine ganz fehlenden Übersetzungsdateien neu anlegt. Irgendwo habe ich gelesen, dass das ein Feature sein soll, also so gewollt ist. Ich will es aber nicht so, und daher ist mal wieder ein Skript-Gefrickel (merge-central.sh) entstanden, das eine Art Rundumschlag darstellt, aber eben funktioniert:

#!/bin/bash
 
cd comm-central
cp -r comm-central/mozilla/browser/locales/en-US/* de-merge/de/browser
cp -r comm-central/calendar/locales/en-US/* de-merge/de/calendar
cp -r comm-central/chat/locales/en-US/* de-merge/de/chat
cp -r comm-central/mozilla/dom/locales/en-US/* de-merge/de/dom
cp -r comm-central/mozilla/extensions/irc/locales/en-US/* de-merge/de/extensions/irc
cp -r comm-central/mozilla/extensions/venkman/locales/en-US/* de-merge/de/extensions/venkman
cp -r comm-central/mail/locales/en-US/* de-merge/de/mail
cp -r comm-central/mozilla/mobile/locales/en-US/* de-merge/de/mobile
cp -r comm-central/mozilla/netwerk/locales/en-US/* de-merge/de/netwerk
cp -r comm-central/suite/locales/en-US/* de-merge/de/suite
cp -r comm-central/mozilla/toolkit/locales/en-US/* de-merge/de/toolkit
compare-locales -m enxde comm-central/calendar/locales/l10n.ini . de
compare-locales -m enxde comm-central/mail/locales/l10n-central.ini . de
cp -r de/* de-merge/de
cp -r enxde/* de-merge/de

Was passiert hier?

  • Erst einmal werden alle englischen Sprachdateien, die für’s Kompilieren eine Rolle spielen könnten, in einen Ordner „de-merge“ kopiert. Damit geht mir später keine Datei mehr als fehlend durch die Lappen!
  • Dann wird der Stand der de-Übersetzung mit compare-locales überprüft. Dabei wird auch l10n-merge angewandt, das dafür sorgt, dass um englische Bruchstücke ergänzte Sprachdateien vorübergehend im Ordner „enxde“ abgelegt werden.
  • Anschließend werden alle deutschen Sprachdateien nach „de-merge“ kopiert. Entsprechende englische Dateien werden dabei überschrieben. Dateien, die es als de-Variante noch nicht gibt, bleiben in englischer Sprache erhalten.
  • Zuguterletzt werden die durch l10n-merge erzeugten Dateien aus „enxde“ ebenfalls nach „de-merge“ kopiert. Manche in „de-merge“ schon vorhandene Dateien werden dabei überschrieben, da sie zwar vollständig ins Deutsche übersetzt, aber eben unvollständig waren. Ersetzt werden sie durch die ‚Hybriddateien‘, die deutschen und englischen Text aufweisen.

Für’s Bauen muss ich dann noch meine .mozconfig ändern, die Übersetzungsdateien liegen nun schließlich nicht mehr klassisch in „de“, sondern in „de-merge“: ac_add_options –with-l10n-base=../de-merge

Tja, lang hat’s gebraucht, um etwas ganz Kleines zu verstehen, nämlich den Schalter „-m“ von compare-locales. Aber immerhin komme ich nun wieder einfach an deutschsprachige Lightningpakete, unabhängig von (ganz legitimen) unterschiedlichen Übersetzungsgewohnheiten.

Bot-Bottich

Sein Wachstum sei Amazon ja gegönnt (von arbeitsmarkt- und sozialpolitisch Fragwürdigem während des Weihnachtsgeschäfts einmal abgesehen) – aber EC2 nervt! Was diverse offensichtliche und mit der Tarnkappe reisende Bots hier an Anfragen abliefern und sämtliche Pfade abschnüffeln – igittigitt.
Es hilft also nichts, ein Bot-Bottich muss her, in den die Kameraden IP-abhängig abgewimmelt werden. Probelauf gestartet. Wäre schön, wenn’s klappt.

Bauen von Thunderbird/Lightning/Sunbird: Scripte_v2

Letztes Jahr habe ich etwas zu meiner „choice.sh“ geschrieben, mit der ich mir das Kompilieren so bequem wie möglich machen wollte.
Das Ansinnen ist geblieben, das Script ist im Laufe der Zeit immer mal wieder leicht geändert worden, nicht nur wegen diverser Versionsnummern, die anzupassen waren. Jetzt sind es also zwei Scripte, und für  den Fall, dass irgendjemand irgendetwas damit anfangen kann, seien sie hier kurz vorgestellt (Wie beim letzten Mal: Achtung, WP-Syntax verfälscht hier wohl ein paar Zeichen, für Download siehe unten).

Die „choice.sh“ für die ‚aktuellen‘ Bauaufgaben sieht nun so aus und pfeffert damit auch endlich alle Fehlermeldungen ins Buildlog: „Bauen von Thunderbird/Lightning/Sunbird: Scripte_v2“ weiterlesen