Beiträge von jobisoft

Zitat von thosdmg

2.) Bis TB 78 sprang der Cursor nach dem Auswählen der Absenderadresse zum Antworten direkt ins Verfassen Fenster.

Jetzt springt er IMMER in das Adressfeld, obwohl dort ja schon der Empfänger drinsteht.

Ich kümmere mich zeitnah drum:
https://bugzilla.mozilla.org/show_bug.cgi?id=1732558

Zitat von thosdmg

1.) Wenn ich im Posteingang eine Mail markiere, die zwar als gelesen markiert ist, aber noch nicht geöffnet wurde, kann ich zwar auf Antworten und Weiterleiten klicken und ein Absenderkonto auswählen, aber es passiert - Nichts

Erst wenn ich die Mail öffne und von dort aus arbeite, funktioniert es.

Danach aber auch aus der Liste im Posteingang.

Das hab ich nicht verstanden, wie kann eine email als gelesen markiert sein, wenn sie noch nicht geöffnet wurde? Und wo klickst du auf Antworten?

Zitat von Susi to visit

Naja, das heißt dann letztendlich doch, dass der Entwickler kaum eine Chance hat. In der Theorie zwar schon, aber realistisch gesehen nicht. Es wäre ein sehr, sehr großer Aufwand, verbunden mit dem Restrisiko, dass es am Ende doch keine Möglichkeit gibt.

Und für rollo heißt dass, es gibt Stand heute keine Lösung.

Thunderbird v91 compatibility - Release Status · Issue #264 · thundernest/import-export-tools-ng

Beta Releases v10.1.0-b1 basic support for Thunderbird 91 converted options screen updated WindowListener API v10.1.0-b3.zip fixed #266 fixed #259…

github.com

Ich meinte, bei welcher Thunderbird-Template-Version der Fehler auftrat, ob bei der 91er, der 78er oder der 68er Version. War aber am Ende egal, trat überall auf.

Habs gefixt:
https://github.com/thundernest/po…c1547f0657d0707

Klappt es jetzt ohne Fehler? Danke für Eure Geduld.
https://github.com/thundernest/policy-templates

Ich kann den String (der ja nicht lokalisiert werden muss) wirklich nicht direkt ins ADMX file schreiben? Ich MUSS das in alle ADML files kopieren (mit dem ${string.bla}) ?

Doof.

Ich geh dass dann mal fixen und melde mich.

Diese Zeile?

<definition name="SUPPORTED_ID_0" displayName="Thunderbird 68.0 - *"/>

Welche Version (wegen der Zeilennummer)?

Zitat von Susi to visit

Reverse Engineering betreiben zu müssen, kann man m.E. einem Add-On-Entwicker bei aller Liebe nicht zumuten.

Das ist aber genau was Legacy Add-On Entwickler früher gemacht haben und auch heute noch machen müssen. That's the game. Deswegen war ja die Lernkurve für Add-Ons so extrem, Add-On Entwickler mussten tatsächlich den Thunderbird-Code analysieren. Viele haben Lösungen anderer kopiert und mussten daher nicht alles selber ausknobeln, aber das Grundprinzip bleibt.

Meine Aufgabe ist (unter anderem) Add-on Entwickler zu unterstützen, wenn Sie auf Matrix oder https://discuss.thunderbird.net/groups/addons Fragen stellen. Die Entwickler von ecoDMS sollten Ihr Problem dort schildern, evtl hat ja schon ein anderer Entwickler eine Lösung.

Meinen eigenen Kenntnisstand hast du in #23 bereits zitiert. Ich hatte bis lang keine Zeit das weiter zu verfolgen, aber der Ansatz könnte funktionieren.

Ich weiß, dieser Faden ist sehr alt, aber ich würde gern die Leute erreichen, die damals hier gepostet haben.

Es ist zwar nicht ganz mein Aufgabenbereich, aber ich habe mich der offiziellen policy templates für Thunderbird angenommen. Wer genaueres zum "wie" wissen möchte, kann hier nachlesen.

Die neuen templates gibt es in dem bereits in diesem Faden erwähnten Repository:
https://github.com/thundernest/policy-templates

Mich würde interessieren, ob diese wie erwartet funktionieren. Über Feedback würde ich mich freuen.

Zitat von Altstadt

4) Ihr plant, das künftig für die WE zu verbessern. Beides, Zugriff auf's Dateisystem und Improvement der neuen Print-API.

Ja. Wobei es derzeit noch gar keine Print API gibt. Bug 1719662 [0]

[0] : https://bugzilla.mozilla.org/show_bug.cgi?id=1719662

Zitat von Altstadt

2) Für AddOn-Entwickler ist es derzeit schwierig, weil der Thunderbird sich gerade zwischen zwei Welten befindet. -> Da fällt mir als Lesetipp Die drei Sonnen von Liu Cixin ein. Dreikörperproblem, nicht exakt vorhersagbar.

3) PDF-drucken aus einem AddOn geht derzeit nicht oder nur über "Hacks". Hier wichtig.

Thunderbird bietet beide Welten parallel. Entwickler können wählen. Das neue WebExtension-Entwicklungskonzept ist ein zusätzliches Angebot und Entwickler können und sollen wechseln. Derzeit ist also niemand durch die Einführung des WebExtension-Entwicklungskonzepts gekniffen.

Auf (sehr) lange Sicht wird das Legacy-Entwicklungskonzept abgeschaltet, wenn genügend WebExtension APIs existieren. Oder es wird ein Whitelist-Verfahren geben, sodass bestimmte Add-Ons weiterhin das Legacy-Entwicklungskonzept nutzen können, weil sie was ganz verrücktes/spezielles machen müssen. Der Hauptteil der Add-Ons soll aber das WebExtension-Entwicklungskonzept nutzen, weil es für alle Beteiligten besser ist: Weniger crashs bzw. UI glitches in Thunderbird weil Add-Ons nicht mehr groben Käse machen können, weniger/kein Aufwand um ein Add-On für die nächste Version von TB kompatibel zu machen.

Wie in meinem letzten Post gezeigt (Link #3), ist FileSystemAccess weiterhin möglich, da der Legacy Zugriff weiterhin möglich ist.

Das PDF Problem ist unabhängig von der Einführung des WebExtension-Entwicklungskonzepts. Auch ohne dessen Einführung hätten Add-On Entwickler das gleiche Problem, nachdem der Drucken-Dialog geändert wurde. Es hat sich noch kein Add-On Entwickler hingesetzt, das neue System zu reverse-engineeren. Auch damals hat irgendein Add-On Entwickler sich die Zeit genommen, die aktuell genutzte Methode auszuknobeln. Das gesamte Legacy-Entwicklungskonzept kann als Hack bezeichnet werden, war es schon immer.

Zitat von Altstadt

jobisoft, habe ich das richtig verstanden? AddOns können gegenwärtig kein pdf drucken und deshalb ist es in den IET ausgeschaltet? Für PDF/A ist mehr erforderlich als für PDF. Drucken in Datei braucht dann vielleicht einen eigenen Treiber oder vorherigen Eingriff. Für die Archivierung wird das PDF mglw. noch signiert.

Das sind die 2 Seiten des "Legacy" Entwicklungskonzept. Es stimmt, dass in früheren Zeiten Add-On Entwickler beim Core-Team nachfragen konnten, ob eine bestimmte Funktion besser exponiert werden kann, sodass Add-Ons diese besser und einfacher nutzen können. Auch waren die Entwickler bemüht, Core Funktionen nicht radikal zu ändern, weil dadurch Add-Ons kaputt gehen. Das hat über die Zeit aber zu dem sogenannten Developer tax geführt [0]. Deshalb hat Firefox dann irgendwann das WebExtension Konzept eingeführt. Dieses Konzept ist gut. Firefox hat es nur zu schnell eingeführt, und den alten "Legacy" Zugriff gesperrt, bevor genügend WebExtension APIs fertig waren. Thunderbird hat das nicht gemacht. Wenn es eine API noch nicht gibt, dann können Add-Ons einfach auf den "Legacy" Zugriff zurückgreifen und es so wie früher machen.

Mit der Einführung des WebExtension Konzepts hat sich jedoch die Einstellung der Core Entwickler geändert: Sie müssen auf Add-Ons keine Rücksicht mehr nehmen. Der Druck Dialog wurde komplett überarbeitet und so wie Add-Ons das früher gemacht haben, können Sie nun nicht mehr drucken. Das PDF Speichern war ein Hack, in dem Add-Ons den PDF Drucker vor-ausgewählt haben und dann den Drucker-Dialog im "versteckten" Modus aufgerufen haben.

Ich habe im Rahmen von EIT nicht versucht den neuen Dialog anzusprechen, weil ich das als Zeitverschwendung ansehe. Neuer Code sollte immer versuchen dem WebExtension Konzept zu folgen, um der Abhängigkeit vom Core Code zu entkommen. Daher habe ich mich mit verschiedenen PDF Bibliotheken beschäftigt. Wenn ein Add-On Entwickler es unbedingt will, dann wird er es wahrscheinlich auch schaffen den neuen Dialog anzusprechen.

Es gibt aber auch Fälle, wo bestimmt Funktionen tatsächlich einfach nicht mehr so funktionieren wie früher. Es gibt z.B. eine Funktion zum Abtrennen von Anhängen, die in Core zwar existiert, aber nirgends von Core JavaScript aufgerufen wird. Diese Funktion klappt nicht mehr richtig, was einige Add-ons kaputt macht. Weil diese Funktion aber in Thunderbird selbst so nie benutzt wird, ist es kein Bug, den Core fixen wird. Hier müssen Add-ons tatsächlich warten, bis es eine entsprechende WebExtension API gibt. Das könnte auch auf den Drucken Dialog zutreffen.

Zitat von Altstadt

Ich habe gelesen, dass WE-AddOns keinen direkten Schreibzugriff bekommen können. Hört sich so an, als wären wichtige Funktionen des eco gar mehr möglich. Dann könnten die das Teil einstampfen. Bzw Thunderbird wäre für die Anwendung nicht zu gebrauchen.

Es ist gegenwärtig so, dass ich auf eine Entscheidung der Mozilla Leute warte, ob sie die FileSystem API [1] übernehmen oder nicht. Chrome unterstützt diese schon und es wäre schön, wenn Mozilla/Firefox die adaptiert. Ich hab das Thema auch auf die Roadmap für TB 103 gesetzt [2]. Wenn das tatsächlich nicht kommt, dann müssen wir gucken, ob wir für TB etwas Eigenes basteln, Bedarf sehe ich. Solange es noch keine WebExtension API dafür gibt, können Thunderbird Add-Ons weiterhin den "Legacy" Zugriff aktivieren und über den direkten Zugriff auf Core Funktionen lokale Dateien lesen und schreiben [3].

[0]: https://yoric.github.io/post/why-did-m…ove-xul-addons/

[1]: https://web.dev/file-system-access/

[2]: https://developer.thunderbird.net/planning/roadmap#mailextensions

[3]: https://github.com/thundernest/ad…apis/FileSystem

Hey, ich kann da ein paar Infos liefern.

Es ist so, das das Add-On eine Funktion von Thunderbird nutzt, die es so nicht mehr gibt. Der Druck-Dialog wurde komplett überarbeitet und ist nun ein overlay frame. Ruft mal in TB78 und in TB91 die Druckfunktion auf, dann werden ihr das sehen.

Das Add-On versucht nun weiterhin Dinge zu laden, die es nicht mehr gibt. Das müssen sie ändern. Thunderbird wird hier nichts nachbessern, die neue Funktion ist genauso wie sie gewollt ist.

Es gibt zwei Varianten Add-Ons zu entwickeln:

* die alte "legacy" Variante, wo das Add-On direkten Zugriff auf die Thunderbird Oberfläche hat und sich immer an Änderungen in TB anpassen muss

* die neue "WebExtension" Variante, wo das Add-On stabile APIs benutzt und fortwährend funktioniert, auch wenn sich was in Thunderbird ändert.

Das Add-On nutzt wohl Variante 1. Für Variante 2 gibt es noch keine Print API, ist aber für diesen Zyklus aber auf meiner To-Do Liste.

Ich habe keine Ahnung, worauf sich die Aussage bezieht, es muss etwas in TB gefixt werden. Wenn Sie weiterhin die "legacy" Entwicklungsvariante wählen, müssen Sie ihr Add-On entsprechend anpassen. Wenn Sie auf die "WebExtension" Entwicklungsvariante wechseln wollen, dann müsse Sie tatsächlich warten, bis die Print API implementiert ist (ich glaube aber nicht, dass sie das meinen).

VG

John

Aber es ist durchaus auch möglich, dass es ein Hard Limit für die Anzahl der Devices gibt, Microsoft ist da alles zuzutrauen.

Ist eines der Thunderbird Profile auf den diversen Endgeräten ein Clone von einem der anderen (import/export)? Dann haben diese die gleiche "Device ID" und der sync geht kaputt.

Bei den fraglichen Profilen alle TbSync/EAS Konten im TbSync Manager komplett entfernen und neu aufsetzen. Dann wird eine neue ID generiert.

Oh, äh, ich bin der Entwickler. Und ich Supporte die google Funktion nicht mehr:
https://github.com/jobisoft/TbSync/issues/466

Es ist meine Toolbar. Die nimmt sich Platz ohne das TB das weiß und dann ist da zu wenig Platz wenn zusätzliche Elemente eingeblendet werden. Es hilft das Composer Fenster mal größer zu machen und dann den Header-Bereich mal einfach groß zu ziehen und dann zu schließen. Irgend welche Session-Restore-Mechanismen verzögern dann die Platzberechnung bis meine Toolbar auch drin ist.

Aber auch wenn der Trick bei dir nicht funktioniert, das ganze Ding ist ganz klar ein Bug in meinem Add-on.

Feuerdrache: Passiert das nur mit QuickText, oder auch einem anderen Add-On?

Konkretisierung: Ist nur QuickText installiert?

Mein DAV Provider für TbSync unterstütze Google nicht mehr über CalDAV/CardDAV.

Für die Kalender kann TB91 jetzt selbst Autodiscovery. Für die Kontakte hat jemand einen Provider für TbSync geschrieben, der das über Googles eigenes Protokoll macht:
https://addons.thunderbird.net/de/thunderbird…oogle-4-tbsync/

Zitat von Susi to visit

Positiv gedacht, sind sie erstmal vorangeprescht wie die Preußen. Betterbird ist ein Thunderbird, der Fixes für Bugs und Enhancements enthält, die der Thunderbird noch nicht hat. Wenn dieses Fixes zurück in den Thunderbird gehen, wie vielleicht in diesem Beispiel, dann kommt das allen in der Nische zugute.

BB ist schneller, weil er Quick and Dirty patchen kann und nicht das große Ganze im Blick haben muss. So wie das bei jedem Fork ist, der mal eben Dinge ändern will. Seine Patches müssen auch nicht die Test-Infrastruktur durchlaufen und überstehen. Ein Patch von mir hängt z.B. weil ein Mac-Test fehlschlägt und dadurch selbst für Windows/Linux nicht ausgeliefert werden kann. Aber ohne eigenen Mac hab ich das noch nicht debuggen können. Das frisst Zeit. Muss aber sein.

Unser Security Developer ist wieder gesund, von daher geht es bei TB jetzt auch weiter.

Zitat von Matze1866

- Automatische Updates habe ich deaktiviert, das sollte doch klappen oder ? ... damit ich noch warten kann, bevor ich die neue Version 91 update, Thunderbird fragt doch immer erst nach ?

Ja.

Zitat von Matze1866

die zwei einzigsten ADD-ons habe ich auch deaktiviert (ImportExportTools NG und Manually sort folder), oder soll man die besser ganz löschen ?

Wir arbeiten gerade an dem Update für ImportExport Tools, sollte es bis zum TB91 update nicht fertig sein, wird es sich selber deaktivieren (es ist mit "nur mit 78 kompatibel" markiert). Manually sort folder ist schon mit TB91 kompatibel.