...ist es auch so, dass von TB 68 nicht die Kontoeinstellungen vom TB 60.0.8 übernommen werden? Für mich sieht es aus, all müssten sämtliche Settings neu erstellt werden.
Thunderbird 68 übernimmt (oder besser gesagt nutzt diese einfach weiter) - wie gewohnt - alle Einstellungen aus dem vorhandenen Profil. Es muss im Regelfall nichts neu erstellt werden.
ich möchte die Gelegenheit hier einmal nutzen, um zu etwas Ruhe und Gelassenheit aufzurufen!
Danke für den kompletten zugehörigen Beitrag, der alles gut zusammenfasst.
Das Thema hier ist jetzt leider schon ein wenig OT geworden. Im Zusammenhang mit den Add-ons muss ich leider noch darauf hinweisen, dass man Thunderbird bei den Test-Aktionen mit wiederholt neu installierten quasi identischen Add-ons jeweils einmal mit dem Schalter "-purgecaches" starten sollte, damit der XUL-Cache korrekt geleert wird. Sonst wundert man sich, dass die Add-ons hinterher nicht erwartungsgemäß mit neuem Code laufen (und somit Fehler produzieren).
Ahh - sorry. In dem Zip gibt es noch einen Unterordner... Also Zip entpacken und dort rein gehen bis man das erste mal mehrere Ordner sieht. Von dort aus dann alles wieder zippen und als XPI benennen.
Und noch etwas wichtiges bei der ganzen Testerei: Ab Version 68 weigert sich Thunderbird ein Profil zu öffnen, welches zwischenzeitlich mit einer neueren Version verwendet wurde. Von diesem Verhalten wurde ich schon genervt, wenn ich mit verschiedenen Builds (der RC-Versionen) getestet habe. Das wird den Standard-Nutzer hoffentlich nur selten betreffen. Aber beispielsweise in meinem Fall habe ich halt verschieden Sprachversionen auf dem PC, die nicht alle immer die absolut identische Version haben (und RC-1 ist eben schon nicht mehr RC-5 - auch wenn dies nicht auf den ersten Blick ersichtlich ist).
Folgendes ist nicht allgemein gültig, funktioniert aber beispielsweise bei CardBook oder auch meinen Add-ons aus GitLab heraus:
Bei GitLab gibt es "rechts-oben" einen kleinen Button mit einer Wolke und Pfeil nach unten. Drauf klicken, dann im Popup "Zip" wählen und herunterladen. Das dann in XPI umbenennen und fertig ist das Add-on für die Installation 
Vergesst bitte nur nicht, dass dies dann keine offiziellen Versionen der "Add-ons" sind. Ihr habt damit einen bestimmten Entwicklungsstand des Codes herunter geladen und "experimentiert" damit!
Immerhin handelt es sich bei den verfügbaren Downloads des Thunderbird bereits um RC-Versionen. Wenn ich nicht irre ist build-5 momentan die neuste Variante davon. Machen wir uns nichts vor - auch nach dem wirklich offiziellen Release wird es Fehler geben. Wenn es "nur" Dinge wie die Reihenfolge der Tabs sind, dann ist das zwar nervig, aber zunächst mal nichts schlimmes. Dennoch sollte man sich den 68er momentan noch nur bewusst und in Ruhe überlegt installieren und davor am besten (wie immer) ein Backup machen.
"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.
