Beiträge von generalsync

Wenn es um einen einmaligen Umzug geht: Exportiere den Kalender in eine iCal-Datei und importiere diese Datei dann in Thunderbird.

Es gibt dazu leider keine alleinstehende Anleitung, aber der Export ist unter der Überschrift "Exportieren Ihres Kalenders aus Outlook" in dieser Anleitung für Outlook beschrieben. Anschließend in Thunderbird über "Menü | Termine und Aufgaben | Importieren..." die von Outlook erzeugte Datei und einen (ggf. zuvor erstellten, leeren) Kalender wählen. Die Termine aus Outlook wurden damit in den gewählten Kalender kopiert.

Wenn es um eine gleichzeitige Nutzung von Outlook und Thunderbird geht: dafür ist ein separates Tool notwendig. Ein solches Tool wäre z.B. GeneralSync, das derzeit im Rahmen einer Betaphase noch kostenlos genutzt werden kann. Im Falle von GeneralSync würde man nach der Installation die Termine innerhalb von Outlook aus den bisherigen Kalendern in GeneralSync-Kalender kopieren oder verschieben – anschließend lassen sie sich in beiden Anwendungen nutzen. Je nach Bedarf könnte man über WLAN den Kalender dann auch an andere Geräte weitergeben. Vorteil von GeneralSync ist, dass es keinen Server benötigt und alle Daten auf deinem PC bleiben.

Alternativ kann man den Kalender auf einem Server speichern und über das Netzwerk/Internet darauf zugreifen. Je nach Server braucht man dazu in der Regel entweder ein passendes Add-in für Outlook (z.B. für CalDAV-Server) oder entsprechend ein Add-on für Thunderbird (z.B. für Microsoft Exchange).

Disclaimer: ich bin der Entwickler von GeneralSync und daher bei diesem Thema befangen.

Zitat von Naturfreund

Würde die Annahme durch den Hauptentwickler hier publiziert oder sollte ich mir das Add-on von Zeit zu Zeit ansehen, ob es schon aktualisiert worden ist?

Die eigentliche Annahme des Patches selbst wird vermutlich nur im verlinkten Pull-Request publiziert. Ich würde aber erwarten, dass kurz darauf auch eine neue Version des Add-ons veröffentlicht wird.

Du solltest diese nächste Version automatisch bekommen, wenn du das Add-on in deinem Profil zuvor installiert und automatische Updates nicht deaktiviert hast.

Es gibt bereits einen Patch, um ThunderBirthDay in Thunderbird 68 zu nutzen. Der Hauptentwickler des Add-ons hat die Änderungen allerdings bislang noch nicht offiziell angenommen. Bei dringendem Bedarf gibt es im verlinkten Pull-Request auch eine vom Autor des Patches bereitgestellte Vorab-Version (diese Version wurde weder von Mozilla noch vom Hauptentwickler freigegeben, Installation auf eigene Gefahr!).

Zitat von mderrer

Aber bei gemeinsamem Posteingang für viele Adressen / Konten geht das nicht, da wird nach meiner Beobachtung immer die Adresse als Absender gewählt, die zum gemeinsamen Posteingang gehört.

Per Definition hat ein "gemeinsamer" Posteingang kein zugehöriges Konto (bzw. gehört zum besonderen Konto "Local Folders"). Er kann also nicht via IMAP auf einem Server verwaltet werden, sondern liegt lokal auf einem einzelnen PC. Dann funktioniert auch alles wie gewollt.

Dein Problem ist aber etwas anderes: Konten "nur zum Senden" sollte man generell nicht verwenden (abgesehen von wenigen Spezialfällen). Dafür gibt es Aliase, d.h. mehrere Adressen, die zum selben Konto gehören und daher bereits serverseitig denselben Posteingang nutzen. Diese sollten dann von Thunderbird auch beim Senden automatisch gewählt werden – das funktioniert bei mir problemlos. Aliase müssen ähnlich wie Konten auf dem Server angelegt werden – eventuell musst du deine bisherigen Konten vorher löschen.

Ich will das hier aber nicht ausarten lassen, bei Bedarf kannst Du für deine konkrete Situation einen gesonderten Thread erstellen.

Zitat von mderrer

Auch bei einem gemeinsamen Posteingang für alle Adressen / Konten?

An sich ja, bin mir nur nicht sicher, ob mein Setup noch dem "offiziellen" gemeinsamen Posteingang entspricht. Mein Hauptprofil ist über einige Thunderbird-Generationen gewachsen, und in Testprofilen habe ich in der Regel nur eine Adresse.

Die Auswahl der Absenderadresse funktioniert aber aus jedem Verzeichnis innerhalb der Lokalen Ordner heraus – insofern sollte das hoffentlich egal sein?!

Zitat von mderrer

CorrectIdentity hat beim Antworten/Weiterleitgen von Mails (aus einem gemeinsamen Posteingang) automatisch die Absenderadresse umgeschaltet auf die Adresse, an die vorher die Mail geschickt wurde.

Bei mir funktioniert das ganz ohne Add-on genau so. Voraussetzung ist, dass die E-Mail-Adresse auch korrekt in den Konten-Einstellungen hinterlegt wurde, d.h. ohne Tippen als Versandadresse ausgewählt werden kann. Nur beim Verfassen "neuer" Nachrichten muss ich die Adresse selbst wählen.

Probiere es vielleicht mal im abgesicherten Modus oder, wenn das nicht reicht, in einem neuen Profil?

Zitat von Kuerbis42

Gegenprobe mit einem lokalen Kalender: dort erscheint genau dieses PopUp - ich vermute daher den Fehler genau an der Stelle, bei der Abgefragt wird, wo der Kalender "liegt".

Ich vermute, in deinem Test-Profil ist etwas durcheinander (z.B. eine ältere Version von Lightning installiert). Aktuelle Versionen von Thunderbird und Lightning haben dieses Popup nicht mehr – iirc wurde es mit dem Update zu Thunderbird 60 entfernt. Wenn man einen Termin ändern will, ohne dass ein Update gesendet wird, muss man die Updates nun aktiv abstellen (im Teilnehmer-Tab den Haken vor "Teilnehmer benachrichtigen" entfernen).

Mir sind in den aktuellen Versionen keine Probleme bei Einladungen bekannt, auch wenn ich CalDAV nicht explizit getestet habe.

[etwas OT, da im Wesentlichen zu Firefox]

Zitat von Drachen

Wenn man die ohnehin längst toten Erweiterungen mal subtrahiert und sich nicht an bestimmten Namen fastbeißt, sind die "Verluste" an tatsächlicher Funktionalität, wenn überhaupt vorhanden, nur gering.

Jein. Fast alle Funktionen waren in den Developer- und Nightly-Versionen noch zugänglich (das sind sie glaube ich sogar bis heute), aber wurden für die Release-Versionen gezielt deaktiviert. Zumindest in den von Mozilla veröffentlichten Versionen, wenn man Firefox selbst compiliert kann man das natürlich ändern.

Begründung: da ein Add-on so unbegrenzte Berechtigungen hat (wie das bisher eben der Fall war) ist es zu gefährlich, als dass es ein Nutzer jemals erlauben darf. Dazu kommt, dass Mozilla alle Add-ons prüfen und freigeben will - es ist Nutzern nicht mehr gestattet, selbst ein Add-on zuzulassen, das nicht vorher von Mozilla geprüft wurde. Wer das will soll zur Developer-Version greifen (oder, wenn WebExtensions reichen, ESR).

Das betrifft alle Funktionen die Mozilla für "falsch" hält oder für die keine Ressourcen bei Mozilla verfügbar sind/waren. Erstere betreffen vor allem Bedienkonzepte, letztere wurden und werden natürlich noch nachgereicht. Das Problem ist aus meiner Sicht also weniger technisch als sozial: dadurch dass Mozilla die Alleinherrschaft über den Browser übernimmt, fühlt man sich als Entwickler ein Stück weit unterdrückt. Das reduziert die Motivation, sehr große Mengen Zeit zu investieren – da Mozilla gezeigt hat, dass sie ihre Macht nutzen um "unerwünschte" Funktionen gezielt zu blockieren und Add-ons als Kollateralschaden in Ihrer Mission sehen.

Mozilla hätte aus meiner Sicht dieselben technischen Änderungen mit einem etwas weniger aggressiven Zeitplan, etwas mehr Offenheit und einem freundlicheren Ton gegenüber Entwicklern auch ohne das ganze Drama hinbekommen können. Thunderbird macht hier eine deutlich bessere Figur.

Zitat von Settler

Die Frage sei erlaubt, für was eigentlich? Das soll kein Vorwurf an die Entwickler sein. Ich sehe die Vorteile für uns Anwender einfach nicht.

Die Änderungen im Add-on-System sollen es auch einfacher machen, Add-ons zu entwickeln: jeder Webentwickler sollte WebExtensions relativ schnell verstehen, während das alte System etwas mehr Eingewöhnung erfordert hat. Dazu kommt ein Berechtigungskonzept, dass potentiell gefährliche Add-ons besser kennzeichnen soll. Darüber hinaus sollen WebExtensions wieder weniger regelmäßige Wartung brauchen (vergleichbare Stabilität gab es bis Gecko 2.0 auch im alten System, wurde damals zugunsten einer schnelleren Entwicklung von Firefox wieder eingestampft). Sonstige Änderungen sollen in der Regel die Stabilität und Performance erhöhen (z.B. Hardwarebeschleunigung) – selbst wenn der PC nicht angelastet ist kann das z.B. den Energieverbrauch reduzieren. Dazu kommen noch neue Web-Features, die z.B. zur korrekten Darstellung zukünftiger HTML-Mails notwendig sein können.

Wichtiger ist aber ein anderer Punkt: Software wie Thunderbird funktioniert nicht ohne regelmäßige Wartung, und durch das Mittragen der Änderungen kann das Thunderbird-Team für den gemeinsamen Codeteil das deutlich größere Team von Firefox "mitbenutzen". Solange die so gesparte Arbeitszeit größer ist als die zusätzliche Arbeit zum Mittragen der Änderungen, kann das sinnvoll sein.

Verstehe mich nicht falsch, ich finde einen Großteil der "sichtbaren" Änderungen von Mozilla auch eher negativ. Aber wo sich nichts "ändert" wird eben dennoch gearbeitet, und das in der Regel relativ gut und viel. Ich würde grob schätzen, dass mindestens 90% der für eine Software notwendige Aufwand für Anwender nicht direkt sichtbar ist. Man könnte diese Arbeiten aber nicht einfach weglassen, sonst würde die Software nicht oder nur unzuverlässig und/oder unsicher laufen. Diesen Aufwand unterschätzt man leicht – übrigens auch als Entwickler^^

Wenn man Thunderbird direkt von Mozilla weg auf eine andere, stabilere Plattform migrieren könnte, wäre das sicherlich eine Überlegung wert. Das ist aber nicht realistisch, da die Kosten eines solchen Wechsels astronomisch sind: ich würde mindestens den Aufwand annehmen, der für eine vollständige Neuentwicklung von Thunderbird nötig wäre. Dazu kommt, dass in diesem Szenario natürlich auch alle Add-ons vollständig neu entwickelt werden müssten.

TL;DR: Ohne die Änderungen könne das Team bei aktuellem Spendenaufkommen den Aufwand nicht stemmen und es gäbe kein Thunderbird mehr (mittel- bis langfristig). Dein realer Nutzen ist es also, dass Thunderbird weiterhin existiert.

Zitat von Settler

Generalsync [...] Genau die gehen aber möglicherweise verloren.

Ich kann nur für GeneralSync sprechen, aber ich bin da noch optimistisch. Das Thunderbird-Team hat bislang einen unfassbar guten Job gemacht, Add-ons am laufen zu halten. Es wird sich vermutlich viel unter der Haube tun (und damit für Entwickler aufwändig), aber irgendwie wird das schon klappen. Im Gegensatz zum Firefox-Team habe ich nicht den Eindruck, dass gezielt Funktionen dem "Fortschritt" geopfert werden sollen. Wir sind da in guten Händen.

Zitat von Settler

Für den Thunderbird hieße das, den Schritt dann auch irgendwann mitzugehen, was bestimmt auch ein sehr großer Aufwand wird.

Meines Wissens ist nicht geplant, in einem Schritt auf Servo zu migrieren. Stattdessen wird Gecko in Firefox (und damit auch in Thunderbird) sukzessive durch Servo ersetzt.

Wie du richtig bemerkst, ist das für aber für Thunderbird gar nicht relevant: wenn Thunderbird denselben Pfad wie Firefox durchläuft (vor allem die Migration von XUL zu HTML) sollten diese Umbauten ohne größere Änderungen in Thunderbird auskommen. Ob Gecko oder Servo HTML rendert, ist ja auch völlig egal. Technisch ist Thunderbird schließlich nach der Migration eine Art Webseite und sollte daher ohne Veränderung von jeder Browser-Engine gerendert werden können. Im Detail gibt es vermutlich natürlich noch ein paar "Kleinigkeiten" zu klären – aber der Aufwand ist nicht vergleichbar mit einem Fork.

Wenn die Migration abgeschlossen ist, wäre es vermutlich auch deutlich einfacher, Gecko/Servo/Firefox bei Bedarf durch einen anderen Browser-Unterbau zu ersetzen. Ob das sinnvoll wäre ist aber eine andere Frage... die Alternative ist schließlich auch nicht so rosig.

Zitat von Settler

Was wohl besser angenommen würde, ein Thunderbird zunächst ohne neue Features aber dafür mit allen Erweiterungen, wie wir sie jetzt kennen, oder ein Thunderbird auf Basis der neuesten Technologien von Mozilla, dafür aber mit nur sehr wenigen Erweiterungen?

Die Thunderbird-Entwickler sind sich weitgehend einig, dass letzteres der Fall wäre. Wobei die erste Option natürlich vollständig heißen müsste "ein Thunderbird mit allen Add-ons sowie zunehmend größeren Stabilitäts- und Sicherheitsproblemen". Primäres Argument ist, dass die allermeisten Nutzer überhaupt keine Erweiterungen nutzen (von Lightning mal abgesehen, aber das soll ohnehin integriert werden).

Zitat von tempuser

Im Moment gibt es auch noch recht wenige WebExtensions APIs für Thunderbird und noch weniger Beispiele davon in Aktion, sodass man nur sehr schwer anhand von Beispielen die Benutzung der neuen Schnittstellen und Techniken erlernen kann. Leider!

Dokumentation für die aktuelle Nightly-Version gibt es hier: https://thunderbird-webextensions.readthedocs.io/en/latest/

Ich würde erwarten, dass für die verfügbare API nach und nach auch mehr Beispiele dazukommen. Vielleicht wird kurz vor Thunderbird 76 auch wieder ein Migrations-Guide veröffentlicht, der praktisch nur aus Beispielen besteht. Bis dahin kannst du eigene Beispiele vorschlagen und damit die Dokumentation verbessern. Für viele Anwendungen gibt es aber "noch" keine API.

Angesichts dessen, wie das ganze bei Firefox "funktioniert" hat ist die Situation für mich relativ klar: die Menge an APIs die man brauchen würde, eine auch nur annähernd vergleichbare Funktionalität zu erreichen, kann vom Thunderbird-Team nicht kurzfristig bereitgestellt werden (selbst das sehr viel größere Firefox-Team ist bis heute noch nicht annähernd bei der alten Funktionalität angekommen, obwohl die erforderlichen APIs in einem Browser weniger komplex sind).

Es ist aber auch nicht das Ziel, tatsächlich Add-ons auf dem derzeitigen Stand weiterhin zu ermöglichen. Das Ziel ist es, die beliebtesten Add-ons (und ggf. ein paar Add-ons, deren Autoren die notwendigen Änderungen in Thunderbird direkt beisteuern) weiterhin zu unterstützen. In der Theorie sollen dann weitere Funktionen in den kommenden Jahrzehnten dazukommen, sodass man irgendwann gefühlt wieder auf das heutige Niveau kommt (dafür Add-ons aber nicht mehr für jeden neue Version von Thunderbird angepasst werden müssen und aufgrund der Einschränkungen von WebExtensions etwas sicherer sind).

Das ganze ist aber nicht auf dem Mist der Thundebird-Entwickler gewachsen, sondern eine Konsequenz von Mozilla-Entscheidungen im Bezug auf Firefox. Im Gegenteil: dank massiver Anstrengungen der Thundebird-Entwickler können wir in Thunderbird 60 und 68 noch traditionelle Add-ons nutzen. Auch für die kommenden Versionen werden wir vermutlich nicht im Stich gelassen: Im Gegensatz zu Firefox lassen die Thunderbird-Entwickler aber auch sogenannte Webextension Experiments zu. Das sind im Prinzip ganz normale, traditionelle Add-ons als Anhängsel einer WebExtension – darüber kann sich dann jeder Add-on-Entwickler seine eigenen WebExtension-APIs bauen. XUL-Overlays, etc. fallen zwar weg, aber technisch geht damit alles, was heute mit Add-ons funktioniert.

Wichtiger Nachteil: für die Experiments bleiben alle Probleme von "normalen" Add-ons bestehen: d.h. große Umbauten im Add-on-Teil bleiben für jede Version von Thunderbird notwendig. Im Gegensatz zu Firefox bleibt damit aber die gesamte (scriptbare) Funktionalität erreichbar.

Ich wäre also vorsichtig optimistisch, dass die Welt damit noch nicht untergeht.

Edit:

Zitat von Settler

Weiß hier jemand, weshalb man den Thunderbird nicht ganz vom Firefox abzweigt?

Firefox/Gecko und Thunderbird sind zu eng verwoben, als dass man sie trennen könnte. Die Trennung wäre vermutlich aufwändiger aus eine vollständige Neuentwicklung von Thunderbird. Und ein Fork von Gecko wäre mit den Ressourcen vom Thunderbird-Team nicht machbar. Gecko bleibt schließlich eine Browser-Engine, auch wenn man es nicht als solche nutzt – und die laufenden Kosten für die Pflege einer Browser-Engine sind enorm.

(Und um der Frage vorzubeugen: Ja, Browser-Sicherheitslücken in Gecko betreffen auch Thunderbird. Sie sind je nach Situation eventuell schwieriger auszunutzen, aber nicht prinzipiell weniger gefährlich. Es ist also keine Option, eine alte Version von Gecko mit bekannten Problemen einzusetzen.)

Zitat von hejo52

ich möchte in meinem Thunderbird-Kalender einen Termin eintragen, der sich jährlich wiederholt (ohne festes Ende), der aber an einen anderen Termin gebunden ist (z.B. XX Tage im voraus).

Im Allgemeinen unterstützt iCal keine Abhängigkeiten zwischen mehreren Terminen (wenn du das meinst?). "10 Tage vor der diesjährigen Instanz von Termin X, oder gar nicht wenn Termin X in diesem Jahr ausfällt" geht also nicht, selbst wenn du direkt in iCal editiert.

Du kannst aber eventuell zwei unabhängige Wiederholungsregeln finden, die das gewünschte Ergebnis liefern. Das geht für die realistischen Fälle auch direkt über die Oberfläche von Thunderbird – iCal kann noch viel mehr, aber bereits der in Thunderbird sichtbare Umfang ist mehr als die meisten Programme von Haus aus unterstützen. Wenn du den Kalender also jemals mit einem anderen Programm oder auf einem anderen Gerät (z.B: Smartphone) nutzen willst, wäre ich bei komplexen Wiederholungsregeln vorsichtig – selbst wenn sie in Thunderbird funktionieren.

Was ebenfalls direkt in Thunderbird geht, ist eine zusätzliche Erinnerung an einen Termin X Tage im Voraus (maximal ein Monat, sonst wird die Erinnerung nicht rechtzeitig angezeigt). Je nach Anwendung kann das eventuell den anderen Termin ersetzen.

Zitat von Thomas S.

Kein funktionierender Import von Outlook nach TB. Nur über Umwege und nicht vollständig möglich.

Im Wesentlichen dazu, aber auch ein bisschen zur Gesamtproblematik: die Funktionalität von Outlook und Thunderbird sind – besonders im Bereich Adressbücher – nicht deckungsgleich. Das entspricht ein Stück weit der Linux-ist-nicht-Windows-Problematik, die ja schon angesprochen wurde. Ein "vollständiger" Import ist daher in keiner der beiden Richtungen möglich.

Das sehe ich besonders bei der Entwicklung meines Synchronisationstools GeneralSync. Einer der größten technischen Herausforderungen war und ist dabei die verlustfreie "Übersetzung" zwischen unterschiedlichen Anwendungen. In der GeneralSync-Dokumentation habe ich die wichtigsten Unterschiede für Kalender und Adressbücher in einer Tabelle der Funktionen je nach Anwendung zusammengefasst. Völlig unabhängig von GeneralSync kann man daran sehen, dass beide Programme Funktionen unterstützen, die keine Entsprechung im anderen Programm haben. Beim Wechsel des Programms gehen also Funktionen (und Daten) verloren – will man alle Funktionen muss man alle Programme parallel nutzen.

Zitat von mrb

Bleibt das Problem mit dem Adressbuch.

Was neben direktem Im- und Export funktionieren sollte: man könnte auch ein beliebiges Offline-Synchronisationstool nehmen, um die Daten von Outlook nach Thunderbird zu migrieren. Dabei muss man zwar "doppelt" Im- und Exportieren (vom lokalen Outlook zum Synchronisationstool und dann vom Synchronisationstool zu lokalen Thunderbird), eventuell ist das in manchen Fällen einfacher, als sich mit der manuellen Konvertierung von Microsoft-Formaten zu befassen. Zumindest meine Testdaten habe ich so immer mal zwischen Thunderbird und Outlook hin- und hergeschoben.

Edit: und noch kurz dazu:

Zitat von Thomas S.

1. Nachrichten in separaten Fenster lesen und löschen öffnet die nächste neuere Nachricht.

Geht nicht wirklich einzustellen (!)

Abstellen sollte gehen:

Thunderbird-Einstellungen | Ansicht | Erweitert | Lesen: "Nachrichtenfenster/-tab beim Verschieben oder Löschen schließen"

Zitat von thosdmg

Profile Switcher - ohne den geht's bei mir nicht, da ich immer zwei Profile aktive habe, ein geschäftliches und ein privates.

Über Kommandozeilenargumente lässt sich ja auch ohne Add-on eigentlich jede denkbare Profil-Situation realisieren ('-P PROFILNAME' startet mit dem angegebenen Profil, zusätzlich '--no-remote' erlaubt einen Start obwohl bereits ein anderes Profil läuft). Was kann der Profile Switcher denn mehr?

Minimize to Tray finde ich auch ärgerlich, wobei die angepasste Version für Thunderbird 60 schon nicht mehr ganz so zuverlässig war wie die früheren Versionen. Bisher ist der Leidensdruck bei mir aber noch nicht groß genug, sich darum zu kümmern

Zitat von Thunder

Den ganzen Ärger rund um Lightning bei den Updates und teilweise plötzlich englischer Sprache (wohl primär bei Linux-Distributionen) hätte man sich und den Anwendern ersparen können. Ursprünglich war halt die Überlegung da, dass man nicht jedem solch ein "überladenes" Programm aufzwingen wollte.

Die Anwendung möglichst modular aufzubauen war aus meiner Sicht keine schlechte Idee und würde auch einigen anderen Funktionen gut tun (z.B. Chat). Wegen nativem Code ist die Trennung von Lightning und Thunderbird inzwischen zwar nicht mehr technisch sauber, aber das war aus der damaligen Perspektive ja nicht abzusehen. Ich würde das also auch rückwirkend nicht als Fehler ansehen.

Problematisch wurde es erst, als Lightning nicht mehr auf AMO (und später auch nicht auf ATO) aktuell gehalten wurde: dadurch dass es technisch ein Add-on ist, aber nicht die Add-on Infrastruktur nutzt, entstehen diverse Probleme in weniger populären Szenarien (lies: bei Linux-Distributionen, die das Add-on nicht gebündelt ausliefern). Insofern stimme ich zu, dass man sich den Ärger hätte ersparen können.

Zitat von maf

Ich vermute, mit Adressbuch-Fenster meinst du das Fenster, das man mit Extras → Adressbuch öffnet? Und da gibt es bei dir ein Symbol mit Pfeil nach unten?

Ja, dieses Fenster meine ich (Bild aus dem Lexikon):

Nein, es ist kein Symbol, sondern eine Schaltfläche mit dem Text "Karte anzeigen", mit dem Pfeil rechts daneben. Sie sollte im unteren Teil des Adressbuch-Fensters (im Bild markiert mit der 3) jeweils rechts neben einer Adresse erscheinen, wenn in der Liste oben ein Kontakt mit einer Adresse gewählt wird. Wenn der Kontakt keine Adressen hat, wird entsprechend auch keine Schaltfläche angezeigt (bei privater und dienstlicher Adresse gibt es entsprechend zwei Schaltflächen).

Da ich die Schaltflächen in verschiedenen Versionen von Thunderbird 60 und Thunderbird 68 sehe, glaube ich nicht, dass diese Funktion von der Version abhängt. Sie könnte aber eventuell je nach Betriebssystem unterschiedlich aussehen.

Zitat von maf

Nur leider finde ich in der Benutzungsoberfläche keine Möglichkeit, solch eine Funktion auszuführen.

Ich bin mir gerade nicht abschließend sicher, ob ich irgendetwas dafür eingestellt habe, aber bei mir gibt im Adressbuch-Fenster rechts neben "Karte anzeigen" einen kleinen Pfeil nach unten. Wenn man dort drauf klickt, wird eine Liste angezeigt, aus der ein Anbieter gewählt werden kann. Wenn man dort OpenStreetMap auswählt, wird für den Knopf "Karte anzeigen" fortan OpenStreetMap genutzt.

Nur kurz eine Anmerkung zu Hintergrundfarben im Allgemeinen:

Zitat von 1caesar

der überwiegende Teil des Felds ist graublau

Dieses graublau ist die Farbe des Kalenders. Du kannst für jeden Kalender in der Liste links eine eigene Farbe bestimmen, die dann für alle Termine genutzt wird. Es gibt also für jeden Termin bis zu zwei Farben: die Kalenderfarbe und ggf. die Farbe der Kategorie.

Bei Bedarf könntest du also statt Kategorien also mehrere Kalender mit unterschiedlichen Farben nutzen. Damit wäre deine Wunsch-Farbgebung möglich. Ob es für Deine Kategorien inhaltlich Sinn macht, jeweils ein eigener Kalender zu sein, musst Du aber natürlich selbst entscheiden.

Disclaimer: Als Entwickler von GeneralSync bin ich bei diesem Thema befangen.

Neben dem Forum gibt es auf dieser Webseite auch ein Lexikon. Der Artikel Synchronisation mit einem Smartphone beschreibt allgemein die verfügbaren Optionen. Prinzipiell musst du dabei zuerst entscheiden, wo Du den Kalender speichern willst:

• Cloud-Dienstleister bieten an, Kalender auf deren Servern im Internet zu speichern. Bei kostenlosen Diensten wird dafür die Erlaubnis zur Auswertung des Kalenders zu diversen Zwecken vorausgesetzt (i.d.R. Werbung und/oder "Verbesserungen" im allgemeinen Sinne). In jedem Fall hat der Dienstleister aber technisch zumindest zeitweilig vollständigen Zugriff auf alle deine Termine. Man muss dem Dienstleister also vertrauen – entsprechend würde ich persönlich Google nicht verwenden wollen.
• Ein eigener Server kann – sofern vorhanden – mit entsprechender Software auch zur Speicherung von Kalendern verwendet werden. Die damit verbundenen Wartungs- und Administrationsarbeiten werden mit weitgehend vollständiger Kontrolle und einer scheinbar unbeschränkten Masse an (selbst einzurichtenden) Optionen belohnt. Darüber hinaus muss man seine Daten keiner fremden Firma anvertrauen.
• Eine direkte Synchronisation benötigt gar keinen Server. Dein PC und dein Smartphone (und ggf. weitere Geräte) tauschen die Daten direkt aus, ohne das ein Server dafür eingerichtet werden müsste. Auch hier muss man seine Daten keiner fremden Firma anvertrauen. Der Funktionsumfang variiert je nach verwendeter Software.

Mit einem Tool wie GeneralSync lässt sich die letzte Option ähnlich komfortabel nutzen wie ein Cloud-Dienst, obwohl keine eigene Wartungsarbeit notwendig ist. Als Entwickler bin ich aber vielleicht in bisschen befangen. Derzeit ist GeneralSync noch in einer kostenlosen Beta.

Einige Empfehlungen für die anderen Optionen befinden sich im Lexikon-Artikel.

___

Edit: wenn es unbedingt Google sein muss (wie die neuen Beiträge vor mir suggerieren, die wurden bei mir noch nicht angezeigt), wurden im Verbindung mit Thunderbird 68 Probleme mit dem Provider-Add-on diskutiert. Vielleicht sollte man den Kalender also wenn direkt einbinden? Da ich kein Google nutze, kenne ich die genaue Konfiguration nicht – aber es gibt wohl eine iCal-URL, die mit einem App-Passwort direkt funktioniert oder ähnliches.

Zitat von Thunder

Ein Pref-Branch ist aber doch gar keine Array, oder irre ich mich?

Nein, aber du kannst einen bekommen (via getChildList). Ich würde aber der Lesbarkeit wegen eher direkt Preferences.resetBranch nehmen, auch wenn die Logik dahinter trivial ist. Beispiele findest du z.B. in den Tests zu Preferences.jsm.