Add-On von ecoDMS zeigt Fehlermeldung

Zitat von milupo

Ich habe von dir die Schnauze voll.

Ich bitte darum, unsere Nutzungsbedingungen zu beachten!

§ 3, 3. Umgangsform

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

Das sind dann genau die Infos, die an den Entwickler sollten. Das wäre wohl ein Job für rollo .

Bei den ImportExportTools-ng habe ich von ähnlichen Problemen gelesen. Siehe hier, vermutlich von dir. : https://github.com/thundernest/im…s-ng/issues/264

Zitat

ImportExport Tools used the printing dialog and the PDF printer to create the PDFs, but that has changed dramatically in TB91. The idea is to use the jsPDF lib instead, and I did get that running. I wanted to use it to convert the output of the html export to a PDF, but the lib has severe issues with inter-word spacing (see example: test.pdf), so I probably will disable PDF support for now to get a partially working version on ATN.It looks like jsPDF is the only lib out there, which is able to create selectable text in the final PDF from an HTML source. All other solutions convert the HTML to an image (and use the browser render engine for that) and add the image to the PDF. The HTML rendering of jsPDF itself seems to be not very good at the moment.The pdfmake lib seems to have a good rendering engine but does not accept HTML but a JSON input format. This seems to provide the missing link.

Dieses Add-On hier macht auch einen Export nach PDF/A, eben für die Archivierung.

Zitat von jobisoft

Für Variante 2 gibt es noch kein Print API, ist aber für diesen Zyklus aber auf meiner To-Do Liste.

Das wird den Entwickler dort bestimmt auch interessieren.

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

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

Ich hoffe, ich stehe nicht auf der Leitung. Ich verstehe dich so.

1) Das alte Konzept war nicht wirklich gut. OK.

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.

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

Die Fehlermeldung, um die es hier geht mal außen vor. Die verstehe ich nicht. Ebenso außen vor der Tonfall. Wenn ich den Rest richtig verstanden habe, lag die Forenkollegin, die stets im Konjunktiv geblieben ist, nicht so falsch. Es kann sein, dass ein Entwickler, der PDF-Print braucht und Dateizugriffe, zurzeit echt gekniffen ist. Das eco Addon wäre eventuell gar nicht zum vollen Laufen zu bringen. Die Lösung hier wäre somit entweder kommt Zeit, kommt Rat oder Tricks und Hacks vom Entwickler, die aber nicht lange Bestand haben. Dann würde ich sagen, es wird Zeit für nur noch WE, mit den von dir angesprochenen zusätzlichen Möglichkeiten.

In jedem Fall vielen Dank für die Erläuterungen. Solche Insidersachen erfährt man sonst nicht.

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

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

Hallo John,

ich wollte mich aus diesem Faden ja eigentlich fortan heraushalten. Nachdem dies aber nunmal ein Hilfeforum ist und ich selbst dazu beigetragen habe, den rollo zu verschrecken, bitte doch noch einmal die Frage, was der Entwickler dieser Erweiterung denn realistisch gesehen machen kann, um das Problem zu lösen.

Zitat von jobisoft

Der Druck Dialog wurde komplett überarbeitet und so wie Add-Ons das früher gemacht haben, können Sie nun nicht mehr drucken.

Zitat von jobisoft

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.

Reverse Engineering betreiben zu müssen, kann man m.E. einem Add-On-Entwicker bei aller Liebe nicht zumuten. In der Theorie mag das möglich sein. Das würde bedeuten, dass der sich durch den Quellcode des Thunderbird arbeitet, den erstmal verstehen muss, um dann nach einer möglichen Lösung zu suchen.

Man muss sich auch fragen, wozu eigentlich? Ich glaube nicht, dass der Leidensdruck für diese Firma so groß wäre, dass sie dafür Reverse Engineering im Thunderbird betreiben und Mannwochen investieren würden.

Die Add-Ons für Outlook, MS-Office und Libreoffice funktionieren schließlich.

Klar ist, es gibt keinen Weg zurück. Das muss man akzeptieren. Ich denke aber, wenn es derzeit keine vertretbare und vor allem auch dauerhafte Lösung gibt, dann werden die das Add-On nicht weiter pflegen. Mit der Konsequenz, dass die wenigen Thunderbird-Nutzer ihrer Klientel entweder auf der 78 bleiben oder gleich zu Outlook wechseln.

Damit zurück zu meiner Einleitung. Du hast dich mit dem PDF-Druck ja selbst beschäftigt und hast dem Entwickler gegenüber sicher einen großen Wissensvorsprung. Gibt es einen Tipp, der zur einer vertretbaren Lösung führt?

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.

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.

Hier die offizielle Aussage von ecoDMS bei Facebook:

Zitat

für die aktuelle Thunderbird-Version 91,X wird bis Ende dieses Jahres (oder etwas früher) ein Update für das entsprechende Plug-in veröffentlicht.

Danke. Dann schaun mer mal. Wenn die das hingekommen, hätten wir vielleicht alle was davon. Denn

Zitat von jobisoft

Viele haben Lösungen anderer kopiert und mussten daher nicht alles selber ausknobeln, aber das Grundprinzip bleibt.

Das wäre dann vielleicht auch die Lösung für die ImportExportTools.

Alle diejenigen, die in PDF/A archivieren, würde sich wohl auch freuen. Denn während das mit Office-Dokumenten seit Jahren reibungslos klappt, ist das für E-Mail häufig noch frickellig und/oder benötigt zusätzliche Programme.

Siehe zum Beispiel hier von der TU Berlin: https://www.ub.tu-berlin.de/fileadmin/pdf/Verlag/UV_pdfaDE.pdf

Im Gegensatz zu früher, wo man seine Dokumente abgeheftet und für Jahrzehnte sicher hatte, sind die heutigen Dokumentformate recht kurzlebig. Für kleine Unternehmen und uns Privatleute ist das mindestens mal ärgerlich. Außer, man kümmert sich eh nicht um eine Archivierung und stellt erst in 10 Jahren fest, das ein wichtiges Dokument nicht mehr lesbar ist. Da ist das PDF/A sehr hilfreich. Und vor allem ISO-genormt.

Zitat von Susi to visit

Alle diejenigen, die in PDF/A archivieren

Ich hatte vor Jahren die Idee, alles in Bits und Bytes zu machen. Rechnungen und andere offizielle Schreiben habe ich gescannt und als PDF gespeichert. Ich habe das nicht durchhalten können. Für ein DMS bin ich zu geizig und scheue die Abhängigkeit. Bin wieder beim Papier.

Zitat von Altstadt

Für ein DMS bin ich zu geizig

Dann schau Dir mal ecoDMS an. Ist wirklich super für relativ kleines Geld!

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

Super. Da gibt es ja eine neue "Kopiervorlage" für die Entwickler, die nicht so nah dran sind. Sehr nett.