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.

“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

• Terminen und Aufgaben mit Hilfe des entsprechenden Dialogs,
• Aufgaben über die “Quick add”-Zeile und
• Terminen per “Click & Drag” in Tages- oder Wochenansicht.

Die Einstellungen lassen sich nun über einen Einstellungen-Dialog der Erweiterung konfigurieren. Eine nahtlose Integration in die Lightning-Einstellungen wäre zwar auch hübsch, ist mir jetzt aber zu aufwendig.
Mehr Features gewünscht? An Voreinstellungen für Kategorien bin ich wie bereits erwähnt gescheitert; denkbar wäre für die Zukunft aber z.B. noch eine Beeinflussung des Titels von neuen Einträgen. Es gibt in den Dateien eine Variable “summary”, die sich leicht mit Wunschdaten füttern lassen sollte…

Apropos Zukunft:
Ich hoffe sehr, dass nicht zu viele Erweiterungen dieser Art für Lightning entstehen werden. Denn “Custom Calendar Defaults” arbeitet mit geringfügig modifizierten Kopien von verschiedenen JavaScript-Dateien von Lightning. Per “override”-Anweisung in der chrome.manifest verwendet Lightning dann nicht mehr die eigenen, sondern die Dateien der Erweiterung. Vermutlich gäbe es Konflikte, wenn andere Erweiterungen auf demselben Weg an denselben Dateien etwas modifizieren wollten…
An dieser Stelle hoffen wir einfach mal. Wenn natürlich jemand ein anderes/einfacheres Verfahren mitteilen möchte, wie man sich in Lightning-Funktionen ‘einklinken’ und diese modifizieren kann – her damit!

Weil die Erweiterung mit modifizierten Kopien von Lightning-Dateien arbeitet, solche Dateien sich im Laufe der Lightning-Entwicklung aber ändern können, bekommt jedes Lightning-Release seine eigene Version von “Custom Calendar Defaults” zugewiesen:

• Custom Calendar Defaults 0.1 für
  Sunbird 1.0b1 bzw. Lightning 1.0b1 + Thunderbird 3.0:
  Download
• Custom Calendar Defaults 0.2 für
  Sunbird 1.0b2 bzw. Lightning 1.0b2 + Thunderbird 3.1:
  Download
• Custom Calendar Defaults 0.4 für
  Lightning 1.0b4 + Thunderbird 5 / SeaMonkey 2.1-2.2:
  Download
• Custom Calendar Defaults 0.5 für
  Lightning 1.0b5 + Thunderbird 6 / SeaMonkey 2.1-2.3:
  Download

Rund um den 27. September ist dann (hoffentlich) die nächste Version verfügbar, denn dann soll eine neue Lightning-Version erscheinen.

Feedback willkommen.

Mit kleinen Eingriffen in die calendar-item-editing.js lässt sich nun schon für Status, Privatsphäre und Priorität eine gewünschte Voreinstellung konfigurieren, die dann beim Erstellen neuer Einträge entsprechende Werte aus den Prefs ausliest und den Dialog anpasst.

Eigentlich würde ich das gerne auch für die Kategorien hinbekommen, aber hier hat auch viel Basteln bislang nicht weitergeholfen. Die Krönung war der folgende Fehler:

Fehler: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: chrome://calendar/content/calendar-item-editing.js :: createEventWithDialog :: line 186"  data: no]

Der sagt mir offenbar, dass die Kategorien “tiefer” im Code verwaltet werden und ich da nicht so einfach was umbiegen kann. Was weiß ich, wann da wo welche Kopien irgendwelcher Objekte oder so angelegt und weiter verwurstet werden. Ist mir zu hoch. Schade. Die Kategorien-Geschichte werde ich daher wohl aufgeben.

Vor der Veröffentlichung einer ersten Version von “Custom Calendar Defaults” muss ich aber mal noch zusehen, dass die individuellen Einstellungen per Einstellungen-Dialog vorgenommen werden können – den gibt’s bisher nicht. Und dann wäre noch zu prüfen, wie sich die Erweiterung bei den ‘abgekürzten’ Wegen zum Erstellen von Terminen und Aufgaben verhält, wenn also der Dialog nicht erscheint…

Hier soll nun kurzfristig die Erweiterung “PrintFix” für Abhilfe sorgen – von der man allerdings auch erstmal wissen muss. Also: ausprobieren und weitersagen, sofern die Leistung stimmt. Zugleich ist das Problem in meinen Augen symptomatisch für die nicht zu unterschätzende Klemme, in der das relativ kleine Kalenderprojekt von Mozilla steckt.

Auf der einen Seite gibt es Probleme, die von Nutzern bemerkt und kritisiert werden und für die diese Nutzer eine Lösung sehen wollen. Möglichst schnell. Damit ein triviales Problem (Kommunikation mit einem Drucker würde man heutzutage wohl als ein solches sehen) zügig verschwindet und man zumindest grundlegende Funktion einer Software uneingeschränkt nutzen kann. Nachvollziehbar.
Auf der anderen Seite ist es mit seit einiger Zeit nur noch rund einem Entwickler offenbar gar nicht so einfach, neben allem anderen ein Problem wie die gestörte Druckfunktion genau zu erforschen, zu verstehen und dann eine saubere, passende Lösung dafür zu finden. Denn das ist der legitime Anspruch von Entwicklerseite gesehen: Lightning soll nicht ein Sammelsurium von Bastellösungen sein, sondern ‘anständigen’ Code bieten.
Im Ergebnis führt das unter den gegebenen Umständen immer wieder mal zu frustrierenden Situationen, hier: Wenig saubere, rein ergebnisorientierte Bastellösungen, die u.U. vorhanden sind (das ist allerdings längst nicht die Regel!), werden nicht eingebaut, ‘saubere’, das tatsächliche Problem beseitigende Lösungen aber ebensowenig, da sie nicht vorhanden sind. So bleibt zwar der Code sauber, zugleich aber Nutzern ein ärgerliches Problem erhalten. Manches braucht dann gefühlt einfach ewig und kann auch vergraulen.

Hmm. Ungünstig. Wie soll sich das ändern, solange das Projekt(-team) nicht wächst? Hoffentlich geht das gut…

Zurück zum konkreten Beispiel: Versuchen wir es mit einem Mittelweg, indem wir die ‘unsaubere’ Lösung zwar nicht in den Code einbauen, sie aber als Erweiterung zugänglich und damit für jeden leicht ausprobierbar machen.
Die Erweiterung “PrintFix” ist nichts anderes als ein Duplizieren von Lightning-Code (calendar-print-dialog.xul, calendar-print-dialog.js, einige Fragmente der Sprachdateien en-US + de) mit den in Bug 351581 angedachten kleinen Änderungen (Dialog offen lassen, Schaltfläche “Abbrechen” in “Schließen” umbenennen). Nach der Installation sollten sich unter Windows auf Anhieb Kalenderdaten drucken lassen.
Getestet habe ich das hier mit Lightning 1.0b1 bis 1.0b4 unter Thunderbird 3 bis 5 (Sunbird 1.0b1 sollte aber auch gehen, SeaMonkey ebenso). Fehler bitte melden.
Die Erweiterung soll nur unter Windows arbeiten und lässt sich auch nur dort installieren, sofern ich mit der install.rdf alles richtig gemacht habe.

PrintFix 0.0.4 für Lightning 1.0b2 – 1.0b5:

Vorläufig kompatibel mit:
Thunderbird 3.1 – 7.0a1
SeaMonkey 2.1 – 2.5a1
Sunbird 1.0b3pre – 1.0pre

PrintFix 0.0.3 für Lightning 1.0b1:

Vorläufig kompatibel mit:
Thunderbird 3.0b4 – 3.0.*
SeaMonkey 2.0b2 – 2.0.*
Sunbird 1.0b1pre – 1.0b1

Die Dateien können hier heruntergeladen werden:
http://www.nadelundhirn.de/krams/exten/index.php?path=printfix/

Um mit der Lightning-Zeit zu gehen, sollte sich die Erweiterung nun auch in SeaMonkey installieren lassen. Außerdem wütete ein wenig die Bastelwut:

• Der Slider schließt sich jetzt von selbst, sobald der Nutzer in dem Erinnerungsdialog eine Aktion ausführt. Denn in dem Fall wurde das Fenster offenbar wahrgenommen und der Nutzer kann selbst die Verantwortung für seine Erinnerungen übernehmen. Er braucht den Slider also nicht mehr.
• Für die hartnäckig Vegesslichen/Verpeilten unter den Nutzern gibt es eine “hidden pref”, die über die erweiterte Konfiguration bearbeitet werden kann: “calAlarmSlider.diehardSlider”. Über sie kann der o.g. erste Punkt beeinflusst werden. Standard ist “false”. Setzt man die pref aber auf “true”, dann schließt sich der Slider eben nicht schon dann von selbst, wenn der Nutzer in dem Erinnerungsdialog eine Aktion ausführt. Der Slider ist also hartnäckiger, er will schon selbst einen Klick abbekommen (jedenfalls wenn er ein permanenter ist).
• Wird das Erinnerungsfenster einfach durch einen Klick auf das Kreuz geschlossen, schließt sich auch der Slider.
• Wenn nach dem Aufpoppen des Erinnerungsdialoges und des dazugehörigen Sliders eine weitere Erinnerung dazukommt oder wegbearbeitet wurde, werden Titel und Text des Sliders aktualisiert, damit dort möglichst nicht eine falsche Anzahl an Erinnerungen angezeigt wird. An dieser Stelle ist das Ding etwas unsauber programmiert, denn ich habe nicht den passenden eventhandler gefunden: “DOMAttrModified” wird tatsächlich 4x je Widget/Erinnerung aufgerufen! Ich hätte etwas benötigt, was nur einmal je Änderung aktiviert wird… Auch habe ich unsaubererweise ein paar Leerzeichen in die Textstrings geschmuggelt, damit die Meldungen nicht abgeschnitten sind, wenn die Strings durch Updates deutlich länger werden als beim ersten Öffnen des Sliders. Aber es scheint zu funktionieren!
• Schließlich habe ich noch ein paar “let”s und “var”s eingefügt, weil Warnungen wegen nicht deklarierter Variablen auftauchten. Ich habe ehrlich gesagt keinen Schimmer, ob das so sein muss oder nur guter Stil ist oder was… Aber so habe ich jedenfalls keine Warnungen mehr.

Nach wie vor: Tipps und Anregungen sind stets willkommen, z.B. was die erwähnten unsauberen Stellen betrifft.

Calendar Alarm Slider 0.0.7:

Vorläufig kompatibel mit:
Thunderbird 3 – 7.0a1
SeaMonkey 2.1 – 2.5a1
Sunbird 1.0b1pre – 1.0pre

Die Datei:
calalarmslider-0.0.7.xpi

Die .diff:
006_vs_007.diff

Neben einer kleineren Änderung am”wording” und dem”required”-Abschnitt für Lightning in der install.rdf ist der neu hinzugekommene Einstellungen-Dialog erwähnenswert. Damit lässt sich nun etwas komfortabler einstellen, ob und wie ein “permanenter” oder ein “intervallartiger” (Ja, so heißt die Variante nun. Verbesserungsvorschläge?) Slider angezeigt werden soll.

Übrigens bin ich mir nur unter Windows  wirklich sicher, dass die Erweiterung wie beabsichtigt funktioniert. Unter Linux z.B. ist dann ja doch vieles anders, allein was das Vorhandensein / die Position des Trays betrifft… Erfahrungsberichte würden mich da durchaus interessieren.

Calendar Alarm Slider 0.0.6:

Vorläufig kompatibel mit:
Thunderbird 3 – 7.0a1
Sunbird 1.0b1pre – 1.0pre

Die Datei:
calalarmslider-0.0.6.xpi

Neben kleineren Anpassungen hinsichtlich der kompatiblen Versionen von Firefox, SeaMonkey und Sunbird wurde die Tinderbox-Liste angepasst, sodass sie nun wieder dem aktuellen Angebot von Mozilla (Stand: 12.06.2011) entsprechen sollte.

Außerdem ist der Einstellungen-Dialog komplexer geworden, weil das Original der Erweiterung schon seit Version 0.4.1 die Möglichkeit mitbringt, sich über Statusänderungen oder auch einzelne beendete Builds all der in Frage kommenden Tinderboxen informieren zu lassen (“Benachrichtigungen”).

Und schließlich: Keine Ahnung, warum die Update-Funktion für “Tinderstatus Extended” aus Version 0.3.2 rausgeflogen war – jetzt sollte sie wieder an Bord sein.

Wie üblich: Nach der Installation kann es zunächst zu einem Fehler kommen, weil die Erweiterung nach einer Einstellung für die Anzahl anzuzeigender Statusleisten-Symbole sucht und keine findet. Sobald aber über den Einstellungen-Dialog eine Zahl festgelegt wurde, sollte nach einem Neustart der Anwendung alles laufen.

Die folgenden Kompatibilitätsangaben gelten nur unter Vorbehalt, wirklich getestet habe ich Tinderstatus Extended 0.4.2 nur mit diversen Sunbird-Builds sowie Firefox 4 und 5.0b5. Und das auch nur unter Windows. Falls Fehler auftauchen: Immer her damit!

Tinderstatus Extended 0.4.2:

Vorläufig kompatibel mit:
Firefox 1.5 – 7.0a1
Seamonkey 2.0a1 – 2.4a1
Sunbird 1.0b1pre – 1.0pre

Die Dateien:
Liste der Änderungen gegenüber dem Original (in Version 0.4.2)
Liste der Änderungen gegenüber Version 0.3.2
Kleine Readme
TinderstatusExtended-0.4.2-fx+sm+sb.xpi

Beim Basteln war mir zuletzt ein Fehler unterlaufen: Der Slider ließ sich nicht mehr schließen, wenn man erst das Erinnerungsfenster geschlossen und dann auf den Slider geklickt hat. Das sollte jetzt wieder funktionieren. Schönen Dank an edvoldi für’s Aufspüren.

Calendar Alarm Slider 0.0.5:

Vorläufig kompatibel mit:
Thunderbird 3 – 3.4a1pre
Sunbird 1.0b1pre – 1.0pre

Die Datei:
calalarmslider-0.0.5.xpi

Darin ist neu eingebaut (und auch gleich als Standard gesetzt) ein permanenter Slider. Ein Erinnerungsfenster poppt auf, ein Slider erscheint und verschwindet erst wieder, wenn man draufgeklickt hat.

Die Entscheidung, ob nun ein permanenter Slider oder ein regelmäßig wiederkehrender Slider angezeigt wird, kann man über eine Option in der erweiterten Konfiguration treffen, nämlich “calAlarmSlider.showPermanentSlider”. “true” heißt “Ja, gib mir den permanenten Slider!!”, “false” heißt “Ich hätte gerne den regelmäßig wiederkehrenden Slider!!”.

Der permanente Slider kann natürlich nervig sein!! Gerade deshalb lässt er sich ja aber abschalten. Hauptsache, es hat möglichst niemand mehr Beschwerden, weil er Erinnerungen verpasst hat…

Zudem gab’s etwas mehr Kompatibilität spendiert, ab Thunderbird 3 sollte sich die Erweiterung jetzt installieren lassen. Sonst bleibt eigentlich alles so, wie es im letzten Post beschrieben worden ist.

Calendar Alarm Slider 0.0.4:

Vorläufig kompatibel mit:
Thunderbird 3 – 3.4a1pre
Sunbird 1.0b1pre – 1.0pre

Die Datei:
calalarmslider-0.0.4.xpi