Beiträge von generalsync

Ich kann den Arbeitsaufwand gerade nur schwer abschätzen, aber um eine weitere Option in den Raum zu werfen: das Anlegen von Kalendern lässt sich theoretisch automatisieren. Zwei Optionen dazu:

1. Die Fehlerkonsole kann beliebigen Code ausführen und hat damit auch zugriff auf den Kalender-Manager
2. Wenn es noch automatischer gehen soll, ließe sich das auch über ein Add-on lösen (d.h. ein Add-on schreiben, dass die Kalender beim ersten Start einrichtet und sich dann selbst deinstalliert, und das Add-on dann in alle Profile schieben).

In beiden Fällen ist ein bisschen Erfahrung mit JavaScript notwendig.

Relevantes Codeschnipsel: den Kalender-Manager erhält man mittels

Auf der Variablen cm können anschließend die für calICalendarManager dokumentierten Methoden genutzt werden, insbesondere

um einen neuen Kalender anzulegen. Mögliche Typen findet die Suche nach '@mozilla.org/calendar/calendar;1?type=' in DXR. Ein vollständiges Beispiel gibt es z.B. in calendar-creation.js.

Verlinkter Code ist jeweils für Thunderbird 60, für Thunderbird 52 oben rechts auf 'Switch Tree' klicken und comm-esr52 wählen. Die Codeschnipsel passen für 52 und 60 gleichermaßen.

Kurze Ergänzung zur allgemeinen Problematik: ob eine Alternative mittelfristig nötig ist, ist noch gar nicht geklärt. Ich weiß inzwischen von mindestens einem Fork des Add-ons, der bzgl. TB 60 begonnen wurde. Bislang gibt es dort aber noch keinen öffentlich sichtbaren Code, insofern nicht zu früh freuen

Auch technisch sieht es nicht so schlecht aus, wie ich bisher dachte: es gibt auch in Thunderbird 60 doch noch eine Möglichkeit, nativen Code aus einem Add-on heraus zu laden (js-ctypes bzw. ctypes.jsm). MinTrayR nutzt das bereits, in einigen Details sind aber – zumindest auf den ersten Blick – Anpassungen nötig. Insofern revidiere ich meine Aussage aus dem vorherigen Thread, dass tiefgreifende Veränderungen nötig sind und rechne in den kommenden Monaten mit einem funktionierenden Fork. Irgendwie hatte ich js-ctypes überhaupt nicht auf dem Schirm...

Wenn es um einen einmaligen Im- und Export geht und Du "normale" Adressbücher genutzt hast: die *.mab-Dateien aus deinem Profilverzeichnis enthalten jeweils genau ein Adressbuch, mit allen Listen. Bei beendeten Thunderbird kann man diese einfach mit einer Datei aus dem alten Profil überschreiben:

history.mab enthält "Gesammelte Adressen"

abook.mab enthält das "Persönliche Adressbuch"

weitere Adressbucher, die zusätzlich angelegt wurden: abook-1.mab, abook-2.mab, ...

Vorher sollte man aber in jedem Fall eine Sicherung machen, für den Fall das irgendetwas unerwartetes schief geht.

Wenn die Adressbücher mit anderen Geräten synchronisiert werden, sollte statt der obenstehenden Methode einfach die reguläre Synchronisationsfunktion genutzt werden – selbst wenn es nur um einen einmaligen Vorgang gehen sollte.

Solaris schrieb:

Dass alte Erweiterungen also nach wie vor unterstützt werden. Ist das nicht richtig?

Ja und nein. Ein Großteil der alten Schnittstellen existiert unverändert weiter, aber es gibt mehr Änderungen als "bisher". Im Gegensatz zur Situation bei Firefox kann ein Add-on aber weiterhin alle internen Schnittstellen nutzen, sodass jede Thunderbird-Funktion weiterhin auch von Add-ons aus erreichbar bleibt.

In der Praxis sind für komplexe Add-ons also einige Änderungen nötig (je nach Add-on mehr oder weniger, aber extensions.strictCompatibility reicht nur selten¹), aber es wurden – im Gegensatz zu Firefox – keine künstlichen Barrieren eingerichtet, die die mögliche Funktionalität von Add-ons einschränken. Im Gegenteil: das Thunderbird-Team hat gute Arbeit geleistet, die aus Firefox resultierenden Beschränkungen für Add-ons aufzuweichen. Ich bin dementsprechend zuversichtlich, dass fast alle Add-ons in ihrer Funktionalität erhalten bleiben könnten. Es ist jedoch Arbeit nötig, bei vereinzelten Add-ons eventuell auch eine vollständige Neuentwicklung. Viele Add-on-Entwickler haben ihre Add-ons auch bereits angepasst.

Ob und wie es nach Thunderbird 60.* mit Add-ons weitergeht, ist aber noch gänzlich ungeklärt.

mrb schrieb:

Aus Erfahrung mit Firefox weiß ich, dass es sehr lange dauert bis es Nachfolgeversionen gibt und diese meistens rudimentär sind und wichtige Funktionen fehlen. Manche Add-ons werden sogar gar nicht mehr angeboten.

Die Situation ist eine andere: das Firefox-Team hat bewusst die Add-on-Schnittstelle vernichtet, ohne sich um Kollateralschäden oder die Entwickler-Community zu kümmern. Die Funktionalität von Add-ons wurde bewusst massiv eingeschränkt, ohne auch nur annähernd vergleichbare Alternativen bereitzustellen. Dazu kommt, dass ein Großteil der "Alternativen" erst nach der Entfernung der alten Schnittstellen eingeführt wurde – es war Entwicklern also technisch nicht möglich, ihre Add-ons zu pflegen. Das frustriert und sorgt zuverlässig dafür, dass betroffene Entwickler ihre Add-ons aufgeben.

Das Thunderbird-Team hat fast alle alten Schnittstellen zum Laufen bekommen. Es sind kleine Änderungen nötig, in einigen Add-ons auch größere – aber es ist technisch weiterhin möglich, (fast) alle Funktionen über Add-ons zu erreichen. Das Problem ist hier aber, dass ein Großteil der Thunderbird-Add-ons seit vielen Jahren von Ihren Entwicklern nicht mehr gepflegt werden. Bislang liefen diese Add-ons ganz ohne Anpassung weiter – das ändert sich nun schlagartig mit Thunderbird 60.

Die Situation ist aus meiner Sicht daher nicht annähernd so verehrend wie die von Firefox. Zumindest populäre Add-ons werden aber vermutlich früher oder später ein Update erhalten – entweder durch Ihre Entwickler selbst oder durch einen versierten Nutzer, der das Add-on verwenden will und es daher notgedrungen selbst anpasst.

¹ Edit im Bezug auf den folgenden Beitrag: ich beziehe mich hier auf Add-ons, die seit Thunderbird 52 kein Update mehr erhalten haben. extensions.strictCompatibility ist für 'kleine' Versionssprünge wie z.B. das Update von Thunderbird 59 auf 60 natürlich häufiger erfolgreich.

Dinole schrieb:

ob die 50-er-Versionen weiterentwickelt werden

Thunderbird 52.* ist an die Entwicklung von Firefox 52.* gekoppelt. Da Firefox 52 mit der Veröffentlichung von Firefox 62 kommenden Monat keine Sicherheitsupdates mehr erhält, wird es auch für Thunderbird 52 keine Updates mehr geben. Das Thunderbird-Team ist viel zu klein, um sich alleine um Sicherheitsupdates zu kümmern.

Die Veränderungen in Firefox sind dementsprechend auch die Ursache für die inkompatiblen Add-ons. Im Gegensatz zu Firefox ist es aber weiterhin möglich, vollwertige Thunderbird-Add-ons zu entwickeln; die Thunderbird-Entwickler kümmern sich darum, dass auch weiterhin vernünftige Schnittstellen bereitstehen Dennoch sind i.d.R. ein paar Anpassungen nötig. Add-ons, die nicht aktiv gepflegt werden, können daher nicht mehr ohne weiteres installiert werden. Das betrifft aber nur Add-ons, die seid Jahren nicht mehr weiterentwickelt und von Ihren Entwicklern aufgegeben wurden.

Für die nächste Thunderbird-Version bahnen sich noch größere Änderungen an, da das Firefox-Team das alten Add-on-System Stück-für-Stück entfernt. Wie es dann im Bezug auf Add-ons weitergeht ist noch vollständig offen.

Es ist meines Wissens nicht mehr möglich, nativen Code in ein Thunderbird-Add-on zu integrieren.

Das Problem ist dabei das Anzeigen des Tray-Icons, die übrigen Funktionen wären bei Thunderbird – im Gegensatz zu Firefox – weiterhin umsetzbar. Mit viel Aufwand wäre es daher eventuell möglich, das Add-on aus Nutzersicht zu ersetzen (das "Add-on" würde dann ein weiteres, von Thunderbird unabhängiges Programm beinhalten, um das Tray-Icon anzuzeigen). Ich glaube aber nicht, dass sich jemand die Mühe machen wird.

Möglicher Workaround: es gibt wohl von Thunderbird unabhängige Programme, die es erlauben, beliebige Anwendungen in den Tray zu minimieren.

prozukunft schrieb:

Wie komme ich auf den Kalender-Tab?

z.B. über das Menü (Termine und Aufgaben|Kalender). Die Liste der Kalender ist dann ganz links unter dem kleinen Übersichtskalender.

Die Fehlermeldungen haben vermutlich nichts mit dem Problem zu tun. Die Fehlerkonsole zeigt nur kurz vorher aufgetretene Fehler, daher kann es helfen, die Exportfunktion anzuklicken, während die Konsole offen ist. Erscheinen dann neue Meldungen?

Die Add-on-Seite ist umgezogen, dementsprechend haben sich die Links auf der Add-on-Seite geändert. Die neuen Links werden im alten TB 52 noch als extern betrachtet (wie z.B. Links auf die Homepages von Add-on-Entwicklern, die seit jeher im regulären Browser öffnen).

Thunderbird 60 sollte relativ bald erscheinen, darin werden die Links wieder "intern" geöffnet werden. Der zugehörige Bug klingt mir nicht so, als würde die Lösung für die verbleibenden paar Tage von Thunderbird 52 zurückportiert werden.

prozukunft schrieb:

Wenn ich unter Termine und Aufgaben auf Exportieren klicke, passiert nichts.

Eigentlich sollte anschließen eine Liste mit Kalendern angezeigt werden, in der der zu exportierende Kalender ausgewählt werden kann. Eventuell wurde eine Fehlermeldung in der Fehlerkonsole protokolliert (Extras|Entwickler-Werkzeuge|Fehlerkonsole)?

Möglicher Workaround: im Kalender-Tab auf den zu exportierenden Kalender rechtsklicken, dann "Kalender exportieren..." wählen. Anschließend sollte direkt der Dialog zum Speichern erscheinen, der Schritt zur Kalenderauswahl wird dann übersprungen.

Ich vermute, dass es darum geht, dass unter "Ansicht|Kopfzeilen" (im Menü) derzeit "Alle" eingestellt ist, aber eigentlich "Normal" gewünscht wird.

Nein, das geht nicht. Theoretisch könntest du den Knopf um ein festes Pixelmaß verschieben und es damit so aussehen lassen als wäre der Knopf in der Leiste. Wenn du aber später Elemente in die Leiste hinzufügst oder sich das Design der Leiste ändert, gäbe es damit Probleme.

Das Problem: CSS kann Elemente nicht innerhalb des DOM verschieben, das kann nur Code (JavaScript oder nativ). Du kannst über -moz-binding aber auch Code einbinden. In der Praxis ist das etwas umständlich, ein Beispiel für Firefox gibt es hier. Alternativ kannst Du auch direkt ein Add-on schreiben, ist vom Arbeitsaufwand ähnlich.

Wenn das Add-on mit der Schaltfläche aktiv gepflegt wird, kannst Du auch mal beim Entwickler nachfragen – das wäre wohl das einfachste.

OTS schrieb:

Wenn man das auf mehreren Rechnern gleich haben möchte, muss man doch auch wieder zwischen beiden Rechnern synchronisieren oder habe ich da was übersehen?

Wenn man das will, gehören die Mails m.E. noch nicht ins Archiv, sondern sollten im aktiven Bestand bleiben. Ich habe bewusst "in einem Profil" geschrieben. Ein lokales Archiv ist eher ein Ort für Mails, die man aus irgendwelchen Gründen nicht löschen kann oder will, aber nicht im täglichen Zugriff haben muss (z.B. alte Rechnungen oder die alten Mails einer Mailingliste).

OTS schrieb:

Habe ich da auch alle Mails und Kalender local verfügbar, ohne dass ich eine Internetverbindung habe? Kann ich ohne Internetverbindung z.B. eine beliebige Mail öffnen und diese beantworten? Ist der Kalender verfügbar?

Mails offline lesen geht, wenn das sogenannte "Bereithalten" aktiviert wurde (unter "Synchronisation & Speicherplatz" in den Konten-Einstellungen). Antworten sollte zumindest im Offline-Modus auch gehen (Mails gehen dann in den Postausgang bis eine Internetverbindung besteht).

Für Kalender nutze ich logischerweise GeneralSync ^{Disclaimer: Ich bin als Entwickler dieses Tools befangen!}. Da dafür keine Internetverbindung gebraucht wird gibt es für mich keinen Unterschied zwischen online und offline. Darüber läuft auch die Synchronisation zwischen verschiedenen Profilen auf demselben Gerät.

Bei CalDAV werden Änderungen prinzipbedingt nur bei aktiver Verbindung zum Server ausgetauscht. Offline Termine einsehen funktioniert bei aktivierter Offline-Unterstützung aber auch hier. In gewissen Grenzen geht wohl sogar das Ändern von Einträgen, bei parallelen Änderungen in mehreren Profilen bzw. auf mehreren Geräten kann es aber Probleme geben.

Bzgl. Ordnerstrukturen und Speicherplatz: die meisten Angebote bieten für den aktiven Datenbestand mehr als genug Platz. Für Archivzwecke kann man ja unabhängig von IMAP in einem Profil eine entsprechende lokale Ablage einrichten. Unabhängig davon bevorzuge ich transparent finanzierte Angebote (d.h. ich zahle mit Geld, nicht mit Daten), als netten Nebeneffekt gibt es dort oft noch weniger Einschränkungen im Bezug auf Speicherplatz und Ordnerstruktur.

OTS schrieb:

Also, wenn ich TB beende und dann irgendwann mal wieder starte, ist der Kalender wieder wie zuvor vorhanden. Wenn also der Pfad zum Kalender, und die Kalenderdatei selber, nicht gespeichert worden wäre, woher wüsste TB/lightning dann, wo die zu öffnende Kalenderdatei zu finden ist?

Die lokalen Kalender stehen im Profil im Unterordner "calendar-data" in der Datenbank "local.sqlite". Das ergibt sich aus den entsprechenden Methoden im Quelltext (https://dxr.mozilla.org/comm-r…calStorageCalendar.js#190).

Wenn Du als Nutzer "Kalenderdateien" für einzelne Kalender wahrnimmst, hast du deine Kalender vermutlich als "Netzwerkkalender" angelegt.

Die "Bastellösung" bezog sich auf das Drumherum: den Nachbau von Ordnerstrukturen, etc. Ich will mich an dem Begriff aber nicht aufhängen, einigen wir uns auf "ungewöhnlich komplexe Installationen"

Ich habe nichts gegen solche Basteleien (im Gegenteil, oft sind solche Tricks nützlich) – die Erfahrung zeigt aber, dass eine "weniger ungewöhnlich/komplexe" Lösung im Alltag normalerweise seltener zickt. Daher die Empfehlung für eine Lösung mit mehreren Profilen.

Solaris schrieb:

Damit meine ich, dass ein physisch vorhandenes Profil von mehreren Betriebssystemen benutzt wird.

Das ist es: ich dachte an "teilen" im Sinne von "zerteilen" (= ein logisches Profil ist in mehrere unabhängige Bestandteile zerlegt worden), nicht an "teilen" im Sinne von "verteilen" (= ein logisches Profil wird von verschiedenen Geräten/Betriebssystemen aus genutzt). Letzteres ist hier natürlich der Fall. Danke für die Klarstellung!

OTS schrieb:

Was meintest Du mit "Während ein Profil geladen war"? Das ich das synchronisieren gestartet habe, während auf einem Rechner TB lief? Nein, das natürlich nicht.

Genau das meinte ich.

OTS schrieb:

Der Pfad zum Lightning-Kalender wird übrigens nicht relativ abgespeichert.

Ich bin mir relativ sicher, dass dieser Pfad für lokale Kalender überhaupt nicht gespeichert wird, er kann ja auch vom Nutzer nicht geändert werden. Du hast eventuell deinen Kalender als "Netzwerkkalender" über eine file://-URL eingebunden? In diesem Fall wird natürlich die eingegebene, absolute URL gespeichert. Wobei die dann eigentlich nicht unter Linux laufen sollte, da es in Linux keine Laufwerksbuchstaben gibt...

In jedem Fall klingt Deine Installation ein bisschen nach Bastellösung. Das geht oft (eine Zeit lang) gut, aber um deine Ausgangsfrage nochmal klar zu beantworten: Du kannst diese Problematiken vermeiden, in dem du Thunderbird so verwendest, wie es gedacht ist (1 Profil auf jedem PC, Daten auf anderen wegen austauschen).

Solaris schrieb:

Gemeint ist vermutlich nicht das Teilen des Profils sondern lediglich das Auslagern der Lokalen Ordner bei Verwendung mehrerer Profile?

Fast. Gemeint ist das Auslagern der Lokalen Ordner, unabhängig davon ob mit einem oder mehreren Profilen. Hier im Forum wurde das meines Wissens oft als "Teilen" des Profils bezeichnet (da die Daten des Profils nun in mehreren Verzeichnissen sind). Wie Du richtig sagst: wenn der Nutzer alle Einschränkungen kennt und beachtet ist diese Funktion stabil. Solche Nutzer wissen das aber eigentlich selber – und sind sich der Probleme bewusst (insbesondere im Bezug auf Parallelbetrieb und Tools von Drittanbietern, z.B. zur Sicherung).

Wenn wir gerade sowieso auf Begriffen herumreiten: entsprechend meinem Sprachverständnis hat OTS seine Profile überhaupt nie geteilt, sondern "nur" regelmäßig zwischen verschiedenen Geräten herumkopiert (mit einem rsync-ähnlichen Tool). Während ein Profil geladen war, war es ja immer vollständig. Oder habe ich irgendwas missverstanden?

OTS schrieb:

Kann es denn tatsächlich sein, dass TB für Windows den Pfad zu den Mails [...] als relativer Pfad ab "Profiles" (da, wo die profiles.ini liegt) abgespeichert wird, während es unter Linux [...] als absoluter Pfad abgespeichert wird?

Könnte zwar sein, aber es ist auch denkbar, dass irgendetwas "zufällig" dafür gesorgt hat, dass der Pfad in einen absoluten Pfad gewandelt wurde – in deinem Fall unter Linux. Da Thunderbird davon ausgeht, dass jedes Profil nur auf einem PC genutzt wird, kann z.B. jedes Update solche Probleme einführen und jede reguläre Funktion könnte solche kleinen Änderungen verursachen.

Das ist auch der Grund, warum wir Dir davon abraten, Dein Setup weiterhin so zu verwenden.

Das Teilen des Profils ohne Nutzung auf mehreren Geräten wird meines Wissens zumindest in engem Rahmen unterstützt (d.h. das verschieben lokaler Ordner auf einen beliebigen absoluten Pfad). Damit gibt es auch häufig Probleme (z.B. mit externen Backup-Tools, die die Mails dann nicht mehr sichern, oder Nutzern, die versehentlich einen der beiden Teile verschieben, umbenennen oder löschen und damit Daten verlieren) – aber diese Probleme werden bei normaler Nutzung von Thunderbird seltener auftreten. Dafür treten sie aber gerne genau dann auf, wenn es darauf ankommt, z.B. bei der Wiederherstellung einer (unwissentlich unvollständigen) Sicherung. Daher ist auch diese Methode nicht zu empfehlen.

Im Wesentlichen stimme ich Solaris zu: die Nutzung desselben Profils auf mehreren Rechnern ist nur sehr selten sinnvoll. Halte die Profile getrennt, solange es irgendwie geht.

Wie das geschieht, ist meines Erachtens aber weitgehend egal. Für E-Mails wird IMAP an Komfort schlecht zu überbieten sein, andere Lösungen funktionieren selten vergleichbar verlässlich und der E-Mail-Provider kann so oder so mitlesen. Bei Kalendern und Adressbüchern: wenn diese in der Cloud oder auf einem Server liegen, lassen sie sich oftmals wie von Solaris beschrieben direkt über die *DAV-Protokolle einbinden.

Ansonsten gibt es auch lokale Synchronisationsmöglichkeiten: Kalender und Adressbücher können in lokalen Dateien außerhalb des Profils abgelegt werden und weiter mit Deinen bestehenden Lösungen synchron gehalten werden (bei parallelem Zugriff jedoch evtl. problematisch), oder ein gesondertes Synchronisationstool übernimmt den Austausch zwischen den Geräten. Als Entwickler eines dieser Tools bin ich bei dem Thema natürlich befangen – wichtig ist mir aber vor allem die Feststellung, dass die Cloud nicht alternativlos ist.

Der Vollständigkeit halber: Einstellungen und sonstige Daten im Profils werden nicht mehr zwischen den Geräten ausgetauscht, wenn jedes Gerät ein eigenes Profil nutzt. Das ist aber in der Praxis selten ein Problem, da die diese Daten im Normalbetrieb nicht geändert werden.

Wenn das Light-Thema gewählt und anschließend neu gestartet wurde, kann ich unter Linux anschließend auch das Dark-Theme wählen. Liegt wohl daran, dass "lightweightThemes.selectedThemeID" keinen korrekten Standardwert hat bzw. ohne Standardwert gelesen wird. Siehe https://bugzilla.mozilla.org/show_bug.cgi?id=1462935