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

Kleinere Aktualisierungen

Einige Tage nach der letzten großen Update-Runde für Lightning, Thunderbird und SeaMonkey habe ich die Erweiterungen „Calendar Alarm Slider“ (jetzt Version 1.0) und „Custom Calendar Defaults“ (stilles Update, keine Versionsänderung) aktualisiert – allerdings nur mit Blick auf die ausgewiesene Kompatibilität. An den Funktionen hat sich nichts geändert.

Die Downloads finden sich hier.

DRM – Hörspielgenuss mal umständlich

Kürzlich habe ich mir ein paar Hörspiele bei Audible gekauft. Ohne großes Rumüberlegen oder Recherchieren. Hätte ich mal machen sollen. Denn mit dem Ergebnis bin ich überhaupt nicht zufrieden:

Abgesehen von der extra Software, die u.a. wegen des Downloads installiert werden soll, werden die Hörspiele in einem speziellen Format angeboten. Die PR-Abteilung will das in erster Linie als besonderen Beitrag zum Hörgenuss verstanden wissen, man darf darüber aber sicher müde lächeln und beruhigt davon ausgehen, dass das DRM-Konstrukt mich vor allem vom unerlaubten Vervielfältigen abhalten soll.

Das führt nur auch dazu, dass ich mein gekauftes Hörspiel nicht so ohne Weiteres ins Nachbarzimmer streamen kann. Oder auf den gewohnten Wegen verwalten. Und die Krönung: Wenn ich die Dinger wie in der Hilfe empfohlen brenne, wird am Anfang und am Ende ein kurzer Werbetext des Anbieters gesprochen. WER BRAUCHT DAS DENN?! Wer will denn zwischen zwei Folgen einer Hörspielreihe was darüber hören, wo das Ding gekauft wurde?

Richtig, niemand. Und deshalb kaufe ich da auch nichts mehr. Umständlich. Ärgerlich. DRM-fixiert eben. Warum so kompliziert? Andere schaffen’s doch auch, ganz normale MP3s zu verkaufen und dabei nicht pleite zu gehen…

 

Mal wieder: Erweiterung “Custom Calendar Defaults” aktualisiert

“Custom Calendar Defaults” liegt nun in Version 1.0 vor, passend zu Lightning 1.2 für Thunderbird 10 und SeaMonkey 2.7. Wer die Erweiterung schon installiert hatte, sollte mittlerweile eigentlich ein Angebot für’s automatische Update zu sehen bekommen haben.

Neue Features gibt’s nicht, allerdings habe ich die Erweiterung ‚unter der Haube‘ etwas verändert. Kurz gesagt geht es darum, nicht mehr vollständige .js-Dateien von Lightning zu kopieren und dann zu modifizieren, sondern nur ausgewählte, für „Custom Calendar Defaults“ relevante Funktionen. Das reduziert Konfliktpotenzial mit denkbaren anderen Erweiterungen, außerdem wird damit der Aufwand reduziert, den ich in die Pflege der Erweiterung stecken muss – denn Änderungen, die außerhalb besagter relevanter Funktionen liegen, müssen nun nicht mehr in eine neue Version der Erweiterung portiert werden.
An dieser Stelle noch einmal Danke an Philipp für Infos dazu, wie sich das bewerkstelligen lässt.

 

Custom Calendar Defaults 1.0:

Kompatibel mit:
Lightning 1.2 mit Thunderbird 10
Lightning 1.2 mit SeaMonkey 2.7

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

Die .diff:
0.9_vs_1.0.diff (etwa 6x so groß wie die .xpi selbst *g*)

Renovierung von Custom Calendar Defaults läuft…

*Grrrrr!!!!*

Stundenlang probiert, Philipps Tipp von neulich umzusetzen, nicht ganze Dateien zu kopieren und zu verändern, sondern sich einfach nur gezielt die Funktionen rauszupicken, die für die Erweiterung von Interesse sind. Und natürlich: Nichts ging! Hin und her, her und hin, mal dieser Fehler, mal jener, mal kein Fehler, dafür dann aber auch keine veränderte Funktion!!

Und…? Na…? Woran hat’s wohl gelegen???

Richtig!! Einfach mal das richtige Ziel für’s overlay angeben, in diesem Fall „calendar-views.xul“ – und schon läuft die Sache!! Das kommt davon, wenn man nur auf das Script schielt und die chrome.manifest dafür *huschhusch* abhandelt…

Jetzt geht’s jedenfalls voran.

Erweiterung „Custom Calendar Defaults“ aktualisiert

Autsch, Rapid Release Cycle tut doch weh. Eigentlich war der Plan, dass es nicht zwei Wochen vom Erscheinen einer neuen Mozilla Lightning-Version bis zur passend gemachten Erweiterung dauert – nun ist es doch passiert. Was soll man machen…

„Custom Calendar Defaults“ liegt nun jedenfalls in Version 0.8 vor, passend zu Lightning 1.0 für Thunderbird 8 und SeaMonkey 2.5. Wer die Erweiterung schon installiert hatte, sollte mittlerweile eigentlich ein Angebot für’s automatische Update zu sehen bekommen haben. Auf drei Dinge möchte ich bei dieser Version hinweisen:

  • Vor einigen Wochen wurde der Wunsch geäußert, dass sich doch bitte auch Standardwerte für die Termin-/Aufgabeneigenschaft „Zeit anzeigen als“ (Beschäftigt/Verfügbar) definieren lassen sollten. In Version 0.8 habe ich das versucht einzubauen, im Einstellungen-Dialog findet sich ein entsprechender Abschnitt. Da diese Eigenschaft in iCalender-Dateien (.ics) über „TRANSP:TRANSPARENT“ bzw. „TRANSP:OPAQUE“ übermittelt wird, versucht die Erweiterung das jetzt ebenfalls auf genau diesem Weg. Bei meinen Tests sah das im Termin- bzw- Aufgabendialog gut aus, die jeweilige Option war stets passend zur Voreinstellung markiert. Ob das dann auch im Austausch mit Kalenderservern läuft, die etwas mit dieser Funktion anfangen wollen, müssten dann bitte mal Leute ausprobieren, die mit solchen Servern arbeitern. Ich tue es nicht. 🙂
  • Hatte ich in Version 0.7 aus Versehen die Voreinstellungen für QuickAdd-Aufgaben aus dem Code geschmissen, die in 0.5 noch drin waren? Ich konnte mich an keinen vernünftigen Grund dafür erinnern – jetzt ist der Kram wieder drin. Solche Missgeschicke entstehen, wenn man nur hin und wieder an einer Erweiterung arbeitet… Irgendwie fängt man dann immer beinahe von Neuem an.
  • Achtung, liebe Nutzer von Google-Kalendern: Neuerdings (?) hagelt es „Modification failed“-Fehler, wenn man den Status eines Termins als „Abgebrochen“ zu definieren versucht. Jedenfalls ist das bei mir so (mit dem Provider 0.9). Das bedeutet: Wenn man als Voreinstellung für neue Termine den Status „Abgebrochen“ definiert (warum auch immer man auf so eine Idee kommen sollte!!), dann wird man beim Anlegen neuer Termine in einen Google-Kalender nicht mehr glücklich.
    Ein Status „Nicht angegeben“ wird bei Google übrigens automatisch zu „Bestätigt“ – nix zu machen.

In der nächsten Version wird die Erweiterung möglicherweise etwas kleiner und auch toleranter gegenüber anderen Ergänzungserweiterungen für Lightning: Philipp vom Kalenderprojekt hat mir neulich einen Tipp zukommen lassen, wie ich auch einzelne Funktionen (und nicht mehr ganze .js-Dateien) ersetzen kann. Leider bin ich bisher nicht dazu kommen, den Tipp einmal auszuprobieren… Wird schon noch werden.

So, für den Moment:

Custom Calendar Defaults 0.8:

Kompatibel mit:
Lightning 1.0 mit Thunderbird 8
Lightning 1.0 mit SeaMonkey 2.5

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

Die .diff:
0.7_vs_0.8.diff