• 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

Ich habe jetzt versucht, die in Bug 329676 ins Spiel gebrachte Idee eines Sliders in Form einer Erweiterung als Nachrüstung zur Verfügung zu stellen, und denke, dass das Dingen fast fertig ist.

So sieht es momentan aus:

Wenn Sunbird oder Lightning ein Erinnerungsfenster öffnen, werden auch das Ovderlay und die paar Bröckchen Code der Erweiterung geladen. Der Code basiert auf dem Toolkit-Slider, nutzt allerdings eine modifizierte Kopie, nicht den Originalcode.

Das alles kann dieser Slider auf diese Weise schon:

• Wenn Sunbird oder Lightning ein Erinnerungsfenster öffnen, geht auch der Slider auf. Er tut dies immer im Vordergrund und zusätzlich zum Erinnerungsfenster. Er informiert darüber, wieviele offene Erinnerungen im Erinnerungsfenster angezeigt werden.
• Wie lange der Slider zu sehen ist, lässt sich über die erweiterte Konfiguration individuell anpassen. Dort gibt es die Pref “calAlarmSlider.totalOpenTime”, für die ein eigener Wert in Millisekunden angegeben werden kann. Danach verschwindet der Slider – scheinbar spurlos. Trotzdem bestehen gute Chancen, offene Erinnerungen nicht zu verpassen, denn:
• Wenn der Slider aufgerufen wird, wird außerdem eine Funktion aufgerufen, die in einem festgelegten Intervall überpüft, ob ein Erinnerungsfenster mit offenen Erinnerungen existiert. Wenn das so ist, erscheint der Slider erneut! Wie groß das Intervall für diese Überprüfung sein soll, lässt sich wiederum über die erweiterte Konfiguration individuell anpassen.Dort gibt es die Pref “calAlarmSlider.checkInterval”, für die ein eigener Wert in Millisekunden angegeben werden kann. Wenn ich also weiß, dass ich öfter nicht am Rechner oder aber abgelenkt bin, wenn dort für mich wichtige Erinnerungen aufpoppen, lasse ich den Slider eben alle 20 Sekunden (= 20000 Millisekunden) aufscheinen und werde so auf jeden Fall zeitnah erinnert. Wenn ich ein gemütlicher Mensch bin, gebe ich dem Slider dafür eben ein paar Minuten… Ausprobieren. Jeder, wie er mag.
• Ein Klick auf den Slider schließt den Slider und gibt dem Erinnerungsfenster den Fokus. Außerdem wird mit diesem Klick die intervallartige Überpüfung abgebrochen: Mit dem Klick hat der Nutzer Aktivität gezeigt, er sollte seine Erinnerungen jetzt registriert haben und ist fortan selbst für alles verantwortlich.

Das kann der Slider (noch) nicht:

• Schön wäre ein Einstellungen-Dialog, um die Konfiguration über ein UI vornehmen zu können.
• Mein Linux ist platt, Mac hatte ich nie: Keine Ahnung, wie das alles auf anderen Systemen als Windows aussieht oder überhaupt funktioniert.
• Schön wäre es, wenn die intervallartige Überprüfung des Slider auch dann abgebrochen würde, wenn der Nutzer von selbst (also ohne Klick auf den Slider) irgendwie das Erinnerungsfenster fokussiert. Bislang erscheint der Slider trotzdem immer wieder, so lange, bis alle Erinnerungen bearbeitet und/oder das Erinnerungsfenster geschlossen wurde(n).
• Die Formulierungen des Sliders sind noch nicht optimal, aber mir ist nichts Besseres eingefallen!
• Ein paar ungenutzte Code-Reste schlummern noch in den Dateien, nicht alles ist aufgeräumt.
• Es könnte Szenarien geben, in denen sich mit den Konfig-Möglichkeiten grober Unfug anstellen lässt. Ich habe die diversen Zeitangaben im Zusammenspiel kaum getestet. Feedback?
• Ich hätte gerne noch das “flashing alarm icon” in den Titel des Sliders eingebaut.
• Die install.rdf bräuchte sinnigerweise noch einen “required”-Abschnitt.

Gerne dürfen Interessierte diese Mankos ausbügeln oder Feedback geben!! Die Ferien sind allerdings so gut wie vorbei, ich werde in absehbarer Zeit nur *sehr* bedingt weiter basteln können… Außer vielleicht an den unterstützten Versionen in der install.rdf, da würde dann ein Update auf 0.0.3 ausgeliefert.

Calendar Alarm Slider 0.0.2:

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

Die Dateien:
calalarmslider-0.0.2.xpi

EDIT:

Version 0.0.3 ist auch mit Thunderbird 3.3a4pre (“Miramar”) kompatibel:

calalarmslider-0.0.3.xpi

Die CSS-Bastelecke im Wiki von sunbird-kalender.de wurde aktualisiert.
Im Grunde findet sich dort nun nicht viel Neues, vor allem habe ich die Einträge, die für Sunbird/Lightning 0.9 zu finden waren, einmal mit Sunbird 1.0 Beta 1 ausprobiert und entsprechend übertragen. Es ist weiterhin so, dass man per userChrome.css viel am Erscheinungsbild des Programms und an der Darstellung verschiedener Einträge verändern kann.

Und ich bin mir sicher, dass sich gerade für Lightning noch das eine oder andere ergänzen ließe, die Oberfläche wird dort schließlich immer komplexer…

Bei Interesse: sunbird-kalender.de: CSS-Bastelecke