Beiträge von jobisoft

Zitat von Thunder

AHT 8.1.2 läuft aber sicherlich mit den 103er Dailies und vermutlich auch darüber hienaus. Man muss es nur manuell dafür "tweaken".

Die Idee ist, dass die Entwickler die Kompatibilität kurz prüfen und dann den Wert in ATN an die jeweils aktuelle Daily anpassen, gerade also 103.0 (so wie ich das z.B. mit Quicktext gemacht habe).

Das Setzen von "*" ist genauso unglücklich und würde uns nächstes Jahr die gleichen Probleme bescheren, wie der "Unfall" mit 102.0 dieses Jahr.

Entwickler melden mir leider zurück, dass dieser Check alle 4-6 Wochen ein zu hoher Aufwand ist. Es würde aber die Benutzerfreundlichkeit drastisch erhöhen, weil die User dann zumindest wissen, dass das Add-on nicht katastrophal Amok läuft. Es war irgendwann mal normal, dass XUL Overlay Add-ons vom Entwickler für neuere Programmversionen freigegeben werden mussten. Dann gab es eine Zeit, wo das Add-on Team die Max-Werte angehoben hat (vor meiner Zeit, ich glaube noch auf AMO). Mit WebExtensions wurde die obere Schranke dann ganz abgeschafft (korrekterweise, da konzeptionell nicht nötig) - für unsere Experimente mussten wir das aber wieder zurückdrehen.

Ich hab noch keine Ahnung, wie ich einen "Freibrief" Modus einbauen kann. Ich grüble noch. Eine Idee ist, in Daily die Max-Limit Checks zu deaktivieren.

Mein Ziel ist aber schon, die Entwickler davon zu überzeugen, dass es für alle Seiten besser ist, alle 4-6 Wochen den Kompatibilitäts-Check zu machen und den Wert dann in ATN anzupassen.

Der parser versteht vCard 4.0, ich weiß aber nicht, ob das irgendwelche Konsequenzen für das UI hat. Die möglichen Einträge im Adressbuch haben sich glaube ich nicht verändert, außer dass jetzt beliebig viele Email-Adressen, Post-Adressen und Telefonnummern gespeichert werden können.

Test: Wenn ich ein Adressbuch über built-in Export exportiere, ist es v4.0.

In Thunderbird 102 werden alle lokalen Adressbücher nach vCard konvertiert und dann gehen auch mehrere E-Mail-Adressen. Release Ende des Monats, wenn alles glattgeht.

Es gibt Pläne für eine Settings API, um ein Subset von Prefs zugänglich zu machen, aber das ist ja für deine AHT Funktion nicht nötig. Du willst ja gerade nicht die globale Einstellung des Users ändern, sondern nur vom aktuellen Tab.

In Thunderbird 91 geht das auch ohne Add-on. Einfach die Konten in der Kontenübersichts-Seite mittels Drag-and-Drop in die gewünschte Reihenfolge bringen.

Edit: Stimmt nicht. Die Ordner lassen sich nicht umsortieren, nur die Konten. Mein Fehler.

Zitat von Thunder

Wobei Dein Tab-bezogener Ansatz auch Dillingers Button auf den Tab eingrenzen könnte/würde und der somit auch gar keinen globalen Rechte mehr hätte bzw. bräuchte.

Genau, das ist mein Ansatz. Niemand braucht Zugriff auf die globalen Einstellungen, sondern nur auf die lokalen, tab bezogenen Einstellungen.

Danke Thunder für die API. Für Thunderbird 102 schaffe ich es nicht mehr, mir das anzugucken, ich habe den "Need Info" offen gelassen, damit ich daran erinnert werden.

Wegen der Abhängigkeit von global Prefs, steht aber auch eine Änderung des Konzepts im Raum: Die globalen Prefs werden nur noch als Vorbelegung einer lokalen Einstellung benutzt (abgelegt im gMessageDisplay Objekt des Nachrichtenfensters). Die Anzeige ist dann nur von diesen lokalen Einstellungen abhängig. Das toggeln der Pref hat dann nur Auswirkungen auf neu geöffnete Nachrichten (weil die Vorbelegung geändert wurde), nicht aber auf bereits geöffnete Nachrichten. Das würde das Rücksetzen-Problem komplett eliminieren und du müsstest nicht mit globalen Prefs arbeiten.

Die Anpassung der Einstellung für ein bestimmtes tab ließe sich dann super in die messageDisplay API einbauen. Hab ich was übersehen?

Das ist doch super aus.

Zitat von Thunder

Jedenfalls habe ich den "need-info" request im Kopf und komme darauf zurück.

Der "need-info" ist an mich Das mache ich, damit ich eine Überblick über die Dinge habe, die ich als nächstes machen will. Aber Feedback zu dem Thema ist auf jeden Fall hilfreich. Danke.

Zitat von Thunder

Das würde ich dann wieder als absolut kritisch ansehen, da ich damit ja auch jegliche Änderung der 3 Einstellungen mittels Thunderbirds eigener UI blockieren würde. Ich möchte dazu erst gar nicht an die Support-Szenarien denken. Das kommt gar nicht in Frage.

Ok, dass kann ich verstehen. Hatte daher die notification vorgeschlagen, die das dem User kommuniziert. Aber das ganz war nur eine Idee, wenn du sie nicht magst, ist das völlig in Ordnung.

Zitat von Thunder

Ich kann mir zur Unterscheidung von current per Thunderbird UI und current per Add-on-Dialog durchaus vorstellen, dass ich dies unterscheiden kann, da ich entsprechende eigene Listener ja beim Umschalten über meinen Dialog vorübergehend deaktivieren könnte. Aber das erscheint mir dennoch alles viel zu kompliziert. Ich muss da mal für heute einen Pause gedanklich einlegen und die nächsten Tage nochmal drauf zurück kommen. Vermutlich werde ich in der Zwischenzeit verschiedenes ausprobieren.

Ja, das scheint zu komplex. Ich wollte es ja gerade einfacher machen, nicht komplizierter.

Die größte Hilfe ist wahrscheinlich, wenn du es dokumentierst und dem User sagts, wo er die Einstellung im TB UI findet.

Zunächst: Das ist alles schon recht fortgeschritten. Dein Add-on hat große Schritte gemacht und die Pref Manipulation ist eine der wenigen Sachen, die mir beim review aufgefallen sind. Wenn es keine einfache Lösung gibt, dann reicht sicherlich auch ein Hinweis auf der Add-on Listing page.

Es gibt ja generell die Möglichkeit, Add-ons in die Liste der vorgestellten Add-ons aufzunehmen, was einen gravierenden Einfluss auf deine Nutzerzahlen haben könnte. Mein Augenmerk liegt hier ganz klar auf neuen Usern, die dein Add-on ausprobieren.

> 1. siehe oben: Dialog beim Deaktivieren/Deinstallieren des Add-ons

Zu deinem Vorschlag bzgl. Dialog beim Deinstallieren: Das geht mit hoher Wahrscheinlichkeit nicht, weil dein Add-on beim shutdown nicht wartet. Wenn der User im Dialog was klickt, ist dein Add-on code wahrscheinlich schon nicht mehr da. Ich selbst hab das noch nicht ausprobiert, habe aber von Dritten gehört, dass es problematisch ist und zu race conditions führen kann.

> 2. Das Add-on verändert nur auf Wunsch des Users Einstellungen. Der User könnte er im Text der Add-on-Dialogtexte darauf hingewiesen werden, dass es sich um Einstellungen handelt, die er in Thunderbird zurücksetzen könnte.

Das ist auf jeden Fall eine gute Idee, wenn dein Add-on nicht die volle Kontrolle über die Pref übernehmen will, sondern nur einen zweiten Weg eröffnen möchte, diese zu ändern. Wie oben geschrieben ist das der Hauptgrund für meine Anmerkung gewesen, da es nicht ersichtlich war, dass es eine Thunderbird-Einstellung ist, die da in deinen Add-On Einstellungen geändert wird.

> Ich verstehe gerade nicht, wann dieses Szenario eintreten soll.

Das Konzept meines Vorschlags war, das AHT die alleinige Kontrolle über die Pref übernimmt, damit du sauber auf einen Urzustand zurückgehen kannst, ohne grübeln zu müssen, was der Urzustand ist (weil die Pref u.U. außerhalb deines AHT option dialogs geändert wurde, egal wie)

original = vor Add-on-Installation

current = die Einstellung, die in deinem AHT options dialog vorgenommen wurde

Beim ersten Start gibt es kein "current" in deiner local storage, also nimmst du einfach den aktuellen Wert der Pref, den du auch in "original" speicherst. Ab diesem Zeitpunkt überwacht dein onChangePref listener die Pref und setz sie bei jeder Änderung (in about:config oder im TB options UI) auf deinen "current" Wert zurück. Du bist der einzige, der die Pref ändern kann. Du musst nix mehr unterscheiden.

Deine Ausführungen in #4 zeigen sehr schön warum die Manipulation von prefs kritisch ist. Idee:

* AHT sieht sich als Hauptverwalter für diese Pref. Das was bei dir eingestellt ist gilt.

* Beim ersten AHT Start/Install ist deine local storage leer, dann speicherst du den aktuellen Wert der Pref als "original" und als "current" in der local storage.

* registriere einen onPrefChange listener auf diese pref, der die pref bei jeder Änderung prüft und wenn er von "current" abweicht, setzt du ihn zurück (nach ein paar millisekunden) und gebe zusätzlich eine notification aus (https://developer.mozilla.org/en-US/docs/Moz…I/notifications) dass AHT die Pref gelockt hat.

* Du selbst kannst die Pref ändern, weil du vor der eigentlichen Änderung den "current" Wert in deiner local storage änderst, sodass der onPrefChange listener dann nix macht.

* Bei add-on shutdown revertest du auf "original" (vorher den onPrefChange listener entfernen)

* Bei add-on start, erzwingst du "current"

Jetzt kann es noch mit einem anderen Add-on, dass die gleiche Methode wählt, ein Gezanke um die Pref geben. Dafür könntest du einen rate limiter in deinen onPrefChange listener einbauen und den User wieder mit einer notification auf diesen Umstand hinweisen. Ich kenn aber derzeit kein add-on, dass das tut.

Das wäre solide, um die ganzen von dir aufgeführten Probleme zu umgehen. Ne andere Lösung fällt mir derzeit nicht ein.

Danke für die Erklärung. Mir ging es um die globale Einstellung "Externe Inhalte in Nachrichten", die dein Add-on schaltet.

Szenario: Aser hat keine Ahnung von den Thunderbird Einstellungen, installiert AHT und nutzt es um die globale Pref zu ändern. Für diesen User ist es nicht ersichtlich, dass er eine globale Pref ändert, sondern er "benutzt dein Add-on".

Er deinstalliert dein Add-on und hat keine Ahnung, wie er diese Einstellung ohne dein Add-On wieder ändern kann. Das gilt es zu vermeiden. Wenn es eine whitelisted prefs API geben wird, dann wird die auch alle Einstellungen zurücksetzen, die von Add-ons verändert wurden. Daher die Bitte: Speichere den Zustand aller prefs, die du dauerhaft änderst und reverte auf diesen Zustand, wenn den Add-on runterfährt.

Der Badge kann auch UTF8 Zeichen, was sehr schick aussieht:

Kommt darauf an, ob du schicke Darstellungen findest, die deine gewünschten Statusanzeigen repräsentieren können (welche sind das nochmal?)

Da es den browser-action-button nicht im message display window gibt, wollte ich davon abraten, den als Statusdisplay zu benutzen, wenn es den nicht überall gibt, da dein UI inkonsistent werden könnte.

Wenn der badge nicht passt, warum kannst du das icon des message display buttons nicht für den status benutzen?

Was die Sache etwas kompliziert macht: Alle action buttons aller tabs/windows sind gleich. Es gibt einen bug der individuelle Eigenschaft vorschlägt, hab da aber noch nicht reingeschaut. Das haben wir von Firefox geerbt.

Der action button ist in stand allone message windows nicht vorhanden, glaube ich. Warum benutzt du nicht direkt den message display button dafür? Du könntest eine badge für den status benutzen, wenn du das icon schon für was anderes verwendest.

Zitat von Thunder

Danke jobisoft

Immer gern.

DAV-4-TbSync wird es für Thunderbird 102 nicht mehr geben, weil Thunderbird jetzt sowohl das auto-discovery der Kalender macht als auch Kontakte beherrscht. Der minimale Vorteil den TbSync noch bietet (Kontake und Kalender zentral zu verwalten, etwas besserer CardDAV sync, Adressbuch UI), rechtfertigt den Aufwand nicht mehr. Wenn ihr nicht das exotische EAS Protokoll (EAS-4-TbSync) oder Google (Google-4-TbSync) benötigt, könnt Ihr TbSync löschen.

Nachtrag: Keine Ahnung, ob Thunderbird inzwischen auch die iCloud Kalender und Kontakte findet, das schien immer noch ein Problem zu sein.

Zitat von Schorsch05

Jetzt habe ich festgestellt, dass neue Kalendereinträge meiner Frau in TB nicht dargestellt werden. Bei meinem Kalender funktioniert alles. Kann mir jemand einen Tipp geben, wie ich die neuen Kalender-Einträge meiner Frau auch in TB sehe?

Der Kalender deiner Frau ist da, aber ist leer?

Zitat von ks-tb

Der Kalender muß manuel aus- und wieder eingeblendet werden um neue Termine sichtbar zu machen. Lässt sich dies noch einstellen ?

Das wurde jetzt zum zweiten Mal reported. Sehr komisch, besonders weil TB91 ja schon so lange draußen ist. Kannst du mal deinen ganzen Account in TbSync löschen und neu anlegen? (Und gucken das nach dem Löschen auch alle Kalender weg sind).

Hilf das?

Du kannst aus

let hasHtmlMimePart = await new Promise(resolve => {
    resolve ( browser.AllowHtmlTempApi.checkMailForHtmlpart(message.id, options.debug) )
  });

einfach

let hasHtmlMimePart = await browser.AllowHtmlTempApi.checkMailForHtmlpart(message.id, options.debug);

machen.

Im obigen Beitrag habe ich die callbacks durch promisses ersetzt. Funktioniert das?