Custom Calendar Defaults 1.5

Die Erweiterung „Custom Calendar Defaults“ hat ein Update auf Version 1.5 erhalten, um mit dem gerade veröffentlichten Lightning 4.0.0.1 Schritt halten (also funktionieren) zu können.
Wie üblich mussten einige Änderungen an Funktionen übernommen werden, die für meine Erweiterung relevant sind. Insgesamt ist die Erweiterung etwas schlanker geworden, weil Lightning nun z.B. von Hause aus Standardeinstellungen für die Privatsphäre bei Terminen und Aufgaben zulässt.

Bei den zuletzt formulierten „Aufgaben für die Zukunft“ hat sich ansonsten fast nichts getan. Immerhin scheint zu klappen, dass nicht mehr benötigte Prefs entfernt werden.
Ich hatte außerdem ausprobiert, inwiefern sich der Einstellungen-Dialog meiner Erweiterung in den ganz normalen Thunderbird-Einstellungen-Dialog integrieren lässt, als Tab, separat oder als Unter-Tab von „Kalender“. Das ist zwar tatsächlich recht einfach möglich, hat aber einen Schönheitsfehler: Wenn man dann im Add-ons-Dialog auf den Schalter „Einstellungen“ von Custom Calendar Defaults klickt, bekommt man den zuletzt sichtbaren Einstellungen-Tab gezeigt – die Einstellungen speziell für die Erweiterung lassen sich bei diesem Aufruf offenbar nicht ansteuern. Das ist unpraktisch, daher habe ich die Idee wieder verworfen.

Fehlermeldungen und Verbesserungsvorschläge sind wie immer willkommen, auch wenn sie eventuell etwas liegen bleiben. 🙂

Custom Calendar Defaults 1.5:

Kompatibel mit:
Lightning 4.0 mit Thunderbird 38
Lightning 4.0 mit SeaMonkey 2.35

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

Die .diff:
1.4_vs_1.5.diff

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

„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

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.

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

Erweiterung „Custom Calendar Defaults“ erschienen

So, die erste Runde ist raus:
Die Erweiterung „Custom Calendar Defaults“ ist denke ich reif genug, um freigegeben zu werden. Mit ihr lassen sich Standardeinstellungen für neue Termine und Aufgaben feslegen, und zwar Einstellungen für Status, Priorität und Privatsphäre. Die Einstellungen greifen beim Anlegen von

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

Erweiterung „Custom Calendar Defaults“ in Arbeit

Das wird die letzte Frickel-Aktion dieser Ferien:
Nachdem ich nun kapiert habe, was man mit „override“- an Stelle von „overlay“-Anweisungen so alles über eine Erweiterung erreichen kann, bastele ich an einer Erweiterung für das Setzen individueller Voreinstellungen beim Anlegen neuer Termine oder Aufgaben in Lightning (vgl. Bugs wie 288157 oder 215975).

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…