"Code" ist für Source-Code. Da macht man kein "Klicki-Bunti-Krams" 
. Das müssen wir uns auch mal selbst sagen lassen 
.
CardBook habe ich in Version 40.9 (bestimmt von GitLab mal selbst geladen und installiert), welches beim mir mit Google-Adressbuch gut funktioniert. Es gibt jetzt aber schon Version 41.1 für Thunderbird 68 auf GitLab.
Du meinst den Papierkorb des Betriebssystems? Das wäre eine Chance.
Ich möchte/muss Eure "Freude" ein wenig trüben:
Zumindest scheinbar. D-h., du siehst sie zwar nicht mehr, sie sind aber weiterhin in den jeweiligen Datenbanken im Thunderbird-Profil vorhanden. Jetzt darf auf keinem Fall irgendein Ordner dieses Kontos komprimiert werden, dann wären sie wirklich weg. Allerdings ist dann das Zurückholen der Mails in Thunderbird ein bisschen zeitaufwendig und mehr für erfahrene Comp-User. Aber weg sind die Mails nicht.
Das gesagte stimmt so wahrscheinlich nur im Fall von "Mbox"-Dateien im Thunderbird-Profil. Wenn man statt dessen das "Maildir"-Format verwendet, werden die Mails eventuell viel schneller unwiderruflich aus dem Profilordner gelöscht (weil Maildir sofort die Datei löscht, statt nur innerhalb der Datei als gelöscht zu markieren) und man kann sich eben nicht damit behelfen, die Mails aus irgendwelchen Mbox-Dateien wieder herzustellen.
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.
Es würde mich nicht wundern, wenn diese Mails in irgend einer Form als HTML und Reintext gesendet und gespeichert wurden, welche nicht ganz standardkonform ist oder anderweitig von Thunderbird nicht erwartungsgemäß behandelt wird.
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 habe bei meinen Addons auch den Cut gemacht und eine reine TB68+ Versionen erstellt und alles alte rausgeworfen.
Mit dem Unterschied, dass es nie eine vernünftige Version des AttachmentExtractors für Version 60 gegeben hat.
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.
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.
Konkrete Thunderbird-Version?
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
Wir müssten den ganzen Block zur Abfrage der Attachmentgröße von hier:
https://gitlab.com/ThunderbirdMai…_window.js#L953
in die Funktion handleAttachment:
https://gitlab.com/ThunderbirdMai…_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.
Musst du mir irgendwie eine merge berechtigung geben?
Das kann sein, ich schaue mal .... sieht eigentlich in den Einstellungen so aus, als könnte jeder (was so aber nicht explizit da steht) einen Merge Request machen. Nur das Approval muss ich als Maintainer bzw. Owner selbst machen. Eigentlich müsste es also gehen. Ich schaue mir später die ganzen Einstellungen noch mal in Ruhe durch.
Deine Datei habe ich zum Testen schon kopiert ich werde diese dann quasi selbst commiten und pushen. Dabei habe ich schon einen Logik-Fehler bei
if (sizeToSmall) {
return;gefunden. Dort muss es wohl korrekt
if (sizeToSmall) {
return aewindow.currentMessage.saveAtt_cleanUp(attachmentindex, true);heißen. Sonst bleibt der ganze Prozess einfach stehen.
Ich habe mir Deine Änderungen in Deinem Repository gerade mal angesehen.
Ist der Grund für Deinen Wunsch nach async gerade an der von Dir umgesetzten Stelle die Performance? Ist das der zeitliche Haupt-Flaschenhals, der bei großen Datenmengen ausbremst? Was soll ich dann mit dem Timeout dort machen? Wenn ich die Folgen richtig verstehe, müsste ich per await / then (oder was auch immer) dafür sorgen, dass es nicht zu Problemen durch async kommt, oder?
Could you make your dev-next-68 branch the default branch (if that is possible with GitLab)?
Sorry, erst jetzt gesehen. dev-next-68 ist jetzt der default branch.
Okay,
ich denke der Code ist für Deinen "Umbau" ausreichend vorbereitet. Alle alten (internen) Routinen habe ich entfernt, soweit diese nicht mehr innerhalb des Codes verwendet werden.
Der Code mit aktuellem Stand hat neben den von uns besprochenen Problemen (Zeitstempel, Mindestgröße und der von Dir "gewünschte" async-Umbau) noch ein kleines weiteres Problem, das ich anschließend angehen würde: Für das Erstellen einer Report-Datei (in den erweiterten Einstellungen des Add-ons) verschluckt sich der Code noch an den theoretisch möglichen CSS-Dateien. Solange man auf CSS komplett verzichtet, funktioniert das Erstellen der Report-Dateien. Sobald aber eine CSS-Datei im Report verlinkt oder direkt eingebunden werden soll, schlägt es fehl.
Ich habe zur Unterscheidung einen Branch "dev-stable-68" erstellt, in dem der momentan funktionierende Code drin ist.
Du kannst nun bitte im Branch "dev-next-68" den async-Umbau etc. vornehmen - Danke!
Wenn du übers Wochenende zunächst erstmal den alten Code rauswirfst, könnte ich am Montag den grundlegenden Umbau hin zu async function machen (den du für fetch() zwingend brauchst). Das ist nicht sehr viel, aber es zu erklären würde länger dauern, als es zu machen.
Dann mache ich Morgen einen neuen Branch auf, in dem ich den alten Code raus werfe und melde mich bis Montag wieder.
N'Abend!
Ich habe jetzt vor meiner weiteren Arbeit wieder ein neues Tag in GitLab erstellt, in dem es eine Menge geänderten Code gibt. Die Änderungen sollten allerdings nicht für die hier besprochenen Probleme relevant sein.
1.) Deine Hilfen zu Zeitstempel der Mail und Größe der Attachments funktionieren (für den console.log).
2.) isLinkAttachment ist vermutlich true, wenn es sich um einen Anhang handelt, der nicht als MIME-Part mit der Mail gesendet wurde - also letztlich quasi extern verlinkt ist?
Wenn ich am Wochenende (trotz, oder gerade wegen, Rufbereitschaft) genügend Zeit habe, werde ich versuchen, Deinen Code dann auch in den Funktionen umzusetzen / zu nutzen.
Puhh, das ist schon Mal super von dir. Ich werde bestimmt 2-3 Tage brauchen, um mir das anzuschauen.
Ich habe relativ wenig Ahnung vom Programmieren, habe aber schon von den Promises gehört. Selbst die Prototypes verstehe ich nicht wirklich und nutze den Code halt so wie er ist.
Bis Morgen werde ich die Menüs wohl fertig überarbeitet und die Favoriten final eingebaut haben. Dann gehe ich an Deine Vorschläge.
Danke
Das wäre bestimmt die beste Lösung, denke ich.
Wenn Dir oder jemand anderem übrigens auf GitLab etwas auffällt, was ich anders machen sollte, dann gebt mir Rückmeldung. Es ist das absolut erste mal, dass ich diese Wochen mit Git / GitLab arbeite. Es ist nicht gerade leicht sich in die Logik der Berechtigungen und der anderen Dinge rein zu denken. Nebenbei verwende ich gleichzeitig auch das erste Mal einen Code-Editor (Visual Studio Code), nachdem ich Jahre lang mit UltraEdit lokal bei mir gearbeitet hatte... Ohne Suchmaschine und Youtube wäre ich wohl verloren 
.