AttachmentExtractor wird zu "AttachmentExtractor Continued" für Thunderbird 60 und neuer

  • jobisoft


    Wir müssten den ganzen Block zur Abfrage der Attachmentgröße von hier:

    https://gitlab.com/Thunderbird…ent/aec_js_window.js#L953


    in die Funktion handleAttachment:

    https://gitlab.com/Thunderbird…ent/aec_js_window.js#L953


    verschieben.


    Dies wäre der korrekte Ort für das Ausschließen von einzelnen Attachments und würde ein paar Folgeprobleme vermeiden.


    Auf Grund des async bekomme ich dies aber momentan nicht hin.

  • D.h. wir verschieben das von AEMessage nach AETask? Bist du sicher?


    Ok, dann reverte zunächst deinen (meinen) letztem Commit, dann ist das async erstmal wieder raus.

    Dann musst du die Funktion getAttSize aus AEMessage rausholen. Du könntest Sie in EATask stecken, oder einfach als normale Funktion ganz nach unten unterhalb von AEMsgWindowCommands definieren:


    Code
    1. async function getAttSize(...) {
    2. ...
    3. }

    Die ist ja unabhängig von irgendwelchen Objekten.


    Nach dem Revert, müsste in saveAtt() wieder der simple Aufruf von getAttSize().then( .. irgendwas mit console.log .. ) drin sein. Den ganzen Block, verschiebst du dann dahin wo du ihn haben willst/brauchst. Hast du in AETask Zugriff auf die prefs?


    Ziel ist, dass du wieder die Größe der Attachments und auch alle relevanten prefs/variablen im log siehst, die wir zur Entscheidung von sizeToSmall brauchen.


    Wenn das wieder klappt, guck ich mir an, welche Funktionen dann alle async werden müssen.


    Meld dich, wenn was unklar ist.

  • Bist du sicher?

    Ja, der "neue" Ort ist der korrekte Ort, um zu entscheiden, welche Attachments bearbeitet werden sollen. Es bleibt ja nicht nur beim Speichern, sondern kommt auch zum Folgeprozess des Löschens (je nach Option), welcher mit der aktuellen Lösung zwar funktioniert, aber im Rückfrage-Dialog zu einem undefined führt. Ich habe das im Code alles sehr gut nachvollziehen können. Man könnte zwar das Problem wieder "umschiffen", aber sinnvoll ist das eher nicht. Besser wir halten uns an die korrekte Reihenfolge der Prozesse.


    Ich mache das dann später und melde mich. Danke

  • Hallo!


    Ein paar ausstehende Rückmeldungen:


    1.) AETask und AEIndTask sind teilweise redundant - keine Frage. Den Sinn davon hast Du sicherlich erkannt, da AEIndTask speziell für den Aufruf über das AttachmentsPane gedacht ist und somit immer nur eine E-Mail behandelt und von der Logik her theoretisch abweichendes Verhalten liefern kann (beispielsweise würde ich persönlich auf die Abfrage der Attachment-Größe in diesem Fall verzichten). Letztlich könnte ich sicherlich versuchen die Redundanz zu reduzieren. Dies würde ich aber eher erst für eine nächste Version des AttachmentExtractor machen wollen, wo man gleich noch ein paar andere Dinge verändern könnte. Im Moment würde ich das Teil gerne zeitnah auf ATN zur Veröffentlichung bringen, um mit Thunderbird 68 eine wirklich lauffähige Version anbieten zu können.


    2.) Deine letzten Änderungen mit den Test-Aufrufen scheinen wieder soweit zu funktionieren, sodass wir bzw. Du dann wieder die async Anpassungen machen könntest.


    3.) Ich habe die zuvor entfernten Zeilen bezüglich a.name versus a.displayName wieder eingefügt, um Problemen vorzubeugen. Auf Dauer möchte ich aber die alten Code-Abfragen bezüglich "tb2", "tb3" und "tb7" aus dem Code entfernen. Unterstützung für Thunderbird 60 und 68 hätte ich eigentlich schon gerne angeboten, aber meine bisherigen Änderungen, um den Optionen-Dialog zukunftsfähig zu machen, waren schon so tiefgreifend, dass es wohl kein Zurück mehr zu Thunderbird 60 gibt. Der Rest wäre wohl noch leicht für 60 und 68 anzupassen.

  • Ich habe bei meinen Addons auch den Cut gemacht und eine reine TB68+ Versionen erstellt und alles alte rausgeworfen.


    ich bin ganz bei dir, so wenig wie möglich zu ändern, um zeitnah auf ATN releasen zu können!


    Ich hab die AETask Sache noch nicht verstanden. Z.B. *wie* wird handleAttachment in AETask eigentlich aufgerufen, also das hier:

    https://gitlab.com/Thunderbird…ent/aec_js_window.js#L470


    Ich vermute, irgendwie implizit, weil irgendeiner API das ganz AETask object als callback übergeben wird, aber wo?


    Bei AEIndTask finde ich zumindest einen expliziten call:

    https://gitlab.com/Thunderbird…ent/aec_js_window.js#L763


    Oder ist das auch der Aufruf für den AETask.handleAttachment, weil that sowohl AETask als auch AEIndTask sein kann?

  • Oder ist das auch der Aufruf für den AETask.handleAttachment, weil that sowohl AETask als auch AEIndTask sein kann?

    Nein, von dort aus wird es nicht aufgerufen. Das kann man per dump erkennen, da die entsprechende dump-Anweisung dann nicht aufgerufen wird. Es muss also irgendwie anders aufgerufen werden. Das habe ich bisher auch nicht verstanden. Vermutlich sollte man auch deshalb vorsichtig beim Entrümpeln der scheinbar Redundanten Funktionen sein.

  • Beachte den letzten Push in den Branch. In den Einstellungen des Add-ons bei Erweitert findest Du ganz unten den Schalter, um die Dumps zu aktivieren (also den "Debug-Modus"). Anschließend findest Du im Profilordner dann die aec_debug.txt Datei.

  • Ich bin das WE familiär stark gebunden und werde nix machen können. Wenn du Zeit hast, könntest du mal versuchen herauszubekommen, durch welchen Aufruf am Ende handleAttachment in AETask aufgerufen wird?


    Danke!

  • durch welchen Aufruf am Ende handleAttachment in AETask aufgerufen wird?

    Ich vermute, das brauchen wir dringend für async? Ich schaue es mir (zum x-ten mal erneut) an und versuche es zu verstehen.


    Ich hatte mir mal einen Crowdin-Account angelegt und bin heute erstaunt, dass man dort monatlich ordentlich Geld blechen muss bzw. müsste. Leider ist BabelZilla inzwischen sowas von veraltet und verschluckt sich beispielsweise an den JSON-Dateien, wenn die im XPI mit drin sind. Nunja, dennoch probiere ich über BabelZilla die Übersetzungen aktualisieren zu lassen, obwohl man das ja auch in GitLab machen könnte.

  • Ich habe jetzt mal eine Version 1.5b1 für Thunderbird 60 und eine Version 2.0b1 für Thunderbird 68 auf ATN hochgeladen. Es sieht dort nur so aus als würde die "ältere" Version dann gar nicht zur Freischaltung kommen, obwohl ich diese ja eindeutig für den "älteren" Thunderbird deklariert habe. Ich bin gespannt, was passiert. In den jetzt hoch geladenen Versionen sind ein paar Kleinigkeiten noch deaktiviert, da diese einfach nicht fertig sind.


    Nachdem meine Version 1.0b1 von Anfang Januar 2019 NIE freigeschaltet wurde (und somit nur versteckt auf ATN auffindbar ist), bin ich gespannt, ob dies jetzt klappt. Wenn nicht, dann habe ich keine Lust mehr, um ehrlich zu sein. Immerhin habe ich jetzt als Amateur vermutlich einen ganzen Arbeitsmonat in die Überarbeitung des Add-ons gesteckt, um mal eine Größenordnung zu nennen.

  • Danke für deine Mühe! Beim Review muss man die Leute anstupsen, ich mach das mal. Der Doppel-Upload wird evtl. so nicht funktionieren, es kann immer nur eine version im review sein. Die jetzt deaktiviert wurde musst du neu hochladen, wenn die andere durch ist.


    Ich muss bei meinen AddOns auch gerade noch nacharbeiten und kann deswegen gerade nicht helfen. Ich melde mich aber, sobald das bei mir durch ist.


    Wie genu heißt das AddOn auf ATN? Gibts ne Seite?


    VG

    John

  • Auf ATN:

    https://addons.thunderbird.net…hmentextractor-continued/


    Hier mal zur Vorschau:

    In den beiden Versionen habe ich folgende Features deaktiviert, da diese noch nicht funktionieren:

    • Auszuschließende Schlüsselwörter für vorgeschlagene Ordner
    • Abtrennen nur ab bestimmter Mindestgröße des Attachments
    • Zeitstempel des gespeicherten Attachments auf Empfangszeit setzen
    • CSS für HTML-Report-Datei

    Für Thunderbird 60 habe ich meine ganze Arbeit zurück portiert und den Einstellungen-Dialog passend zur neuen Version überarbeitet. Auch für Thunderbird 68 wurde der Einstellungen-Dialog nochmals weiter (in 6 Tabs) aufgeteilt.

  • Ach ja, was ich bezüglich ATN beachtet habe: Die Version für Thunderbird 60 bleibt bei der Major-Version 1.* und die Version für Thunderbird 68 macht den Sprung zu Major-Version 2.*. Das sollte so hoffentlich korrekt sein, für das Handling auf ATN.

  • Was mich wundert:


    In den automatischen Tests auf ATN werden in der Version für Thunderbird 60 (also die Version mit install.rdf) ein paar Warnungen ausgegeben bezüglich Überschreibens globaler Variablen (verstehe ich prinzipiell) und bezüglich try / catch. Offensichtlich stört sich der Review-Mechanismus an catch (e) {}?


    Bei identischem Code gibt es aber keinerlei Warnungen für Version 2 für Thunderbird 68. Vermutlich laufen da also ein paar automatische Tests gar nicht? Ich hatte in den letzten Monaten nebenbei den jeweils aktuellen Code immer mal testen lassen - aber eben nur für den 68er (also mit manifest.json). Da gab es nie Fehlermeldungen bzw. Warnungen. Somit war ich gestern dann überrascht, dass für die "ältere" Version dann auf einmal doch ein paar Warnungen erscheinen, obwohl der relevante Code identisch ist.

  • Vermutlich laufen da also ein paar automatische Tests gar nicht?

    Korrekt.

    Sonst hast du alles richtig gemacht.


    Meinen Infos nach ist 2.0b1 bereits freigeschaltet, oder?

  • Das ist so nur bedingt richtig. Man kann das ganze Add-on nur per Direktlink finden/aufrufen, da es noch im (wohl nie stattgefundenen) Review-Prozess ist:


    • Position in der Warteschlange: 9 von 34

    Die Folge davon ist dann eben auch, dass ich keine zusätzliche Add-on-Version hochladen kann, da damit die (gar nicht freigeschaltete) andere Version gleich wieder deaktiviert wird.