Beiträge von jobisoft

  • Tb 78.14 & HostedExchange Cal aufeinmal mit "Verbindung getrennt"

    Das "Kalender getrennt" fügt TbSync zu dem Kalendernamen hinzu, wenn - warum auch immer - der Kalender online nicht mehr verfügbar ist (z.B. eine technische Störung beim Exchange server). In diesen Fall löscht TbSync den lokalen Kalender nicht einfach, sondern markiert ihn als getrennt. Ab diesem Zeitpunkt wird er nicht mehr mit dem Server synchronisiert (also wenn z.B. lokal irgendwelche Termine hinzugefügt werden).

    Wenn der Kalender online wieder verfügbar ist, kannst du ihn neu synchronisieren und evtl fehlende Termine aus dem alten/getrennten Kalender kopieren und dann den alten löschen.

  • Seit TB 91.x seltsames Verhalten der Erweiterung Identity Chooser 3.1

    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?

  • Add-On von ecoDMS zeigt Fehlermeldung

    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

  • Add-On von ecoDMS zeigt Fehlermeldung

    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.

  • Group Policy Templates / ADMX / GPO für Thunderbird 68

    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.

  • Add-On von ecoDMS zeigt Fehlermeldung

    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.

  • Add-On von ecoDMS zeigt Fehlermeldung

    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

  • Add-On von ecoDMS zeigt Fehlermeldung

    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