Allow HTML Temp - Version 7.0 für Thunderbird 91

    Moin!

    Dank jobisoft wurde die (formal) experimentelle WindowListener-API so erweitert, dass ich jetzt auch Allow HTML Temp für den kommenden Thunderbird 91 zur Verfügung stellen kann.

    Die passende Version des Add-ons wird "7.x" sein. Eigentlich verdient diese Version keine höhere Versionssnummer, da sich am Code nur wenig ändert. Aus technischen Gründen auf addons.thunderbird.net macht der Versionssprung auf 7 aber Sinn. Bei mir läuft das Add-on schon in Thunderbird 89 Beta 1 und in den Daily-Versionen.

    Momentan überlege ich noch, ob ich den "alten" Einstellungen-Dialog des Add-ons durch eine neue HTML-Variante des Dialogs ersetze, um wenigstens da schon den Code "moderner" zu machen. Notwendig ist dies aber eigentlich nicht.

    Grund zur Euphorie besteht dennoch nicht, denn ich sehe weiterhin keine Perspektive für AHT, sobald die experimentellen APIs irgendwann nicht mehr von Thunderbird unterstützt werden. Es ist auch keine Begeisterung für solch ein "Nerd"-Feature bei den Entwicklern zu erkennen, denke ich.

    In den nächsten Tagen werde ich Euch hier mit einem passenden Update des Add-ons versorgen.

    Zitat von Thunder

    Momentan überlege ich noch, ob ich den "alten" Einstellungen-Dialog des Add-ons durch eine neue HTML-Variante des Dialogs ersetze, um wenigstens da schon den Code "moderner" zu machen. Notwendig ist dies aber eigentlich nicht.

    Ja! Je weniger code von der WL API geladen wird desto einfacher ist es sich von der WL API zu lösen und dedizierte Experimente zu nutzen / auszulagern, die von mehreren Entwicklern genutzt werden können, sodass sich die Upgrade-Arbeit minimiert. Die WL API verschiebt zwar jetzt auch die Options in den Add-on Manager, aber der Code muss ständig angepasst werden. Wenn du eine HTML options page hast, bist du das Problem auch los.

    Die neue NotifyTools API [1] ist ein weiteres Tools, mit dem du Schritt für Schritt vom WL wegkommen kannst. Die WL API wird definitiv irgendwann sterben (einfach weil sie Code nutzt der irgendwann fliegt), aber für den generellen Erhalt von Experimenten setze ich mich ein und auch Teile des Councils.

    Aber von der WL API solltest du Schrittweise weg migrieren. Ich mache jetzt ja auch wöchentlich live coding sessions...

    [1] https://github.com/thundernest/ad…pport/issues/37

    Hallo Thunder,

    ich weiß ja nicht wie jobisoft das sieht, aber für mich ist das, was AHT zur Verfügung stellt, keine "Nerd"-Funktion, sondern eher eine benutzerfreundliche Funktion, die die Arbeitsergonomie erleichtert, wenn die Voreinstellung für die Mailansicht auf Reintext gesetzt ist.

    Ich kann natürlich nicht beurteilen, was für ein Programmieraufwand erforderlich ist, dies in die Codebasis von Thunderbird unter Verwendung der entsprechenden Programmiersprachen zu integrieren (C, C++, JavaScript, Rust).

    Ebenso kann ich nicht beurteilen, ob es zeitlich noch reicht, dies für Thunderbird 91 umzusetzen, da der Betastand bei 89 und der Dailystand bei 90 ist.

    Ich vermute, dass die verbleibende Zeit dafür zu kurz ist.

    Falls es nicht in die Codebais integriert wird, kann man in der Tat nur hoffen, dass die API vielleicht doch dauerhaft zur Verfügung gestellt wird und ihren experimentellen Charakter ablegt.

    Ich drücke für beide Varianten die Daumen!

    Gruß

    Feuerdrache

    „Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird.“
    Clifford Stoll, amerik. Astrophysiker u. Computer-Pionier

    Zitat von Feuerdrache

    Ich kann natürlich nicht beurteilen, was für ein Programmieraufwand erforderlich ist,

    Direkt im Code ist es für einen Profi vermutlich nur relativ wenig Aufwand.


    Zitat von Feuerdrache

    entsprechenden Programmiersprachen zu integrieren (C, C++, JavaScript, Rust)

    C und C++ werden ja wohl immer weiter durch modernere Sprachen ersetzt.


    Zitat von Feuerdrache

    Ebenso kann ich nicht beurteilen, ob es zeitlich noch reicht, dies für Thunderbird 91 umzusetzen, da der Betastand bei 89 und der Dailystand bei 90 ist.

    Ich vermute, dass die verbleibende Zeit dafür zu kurz ist.

    Da ich es nicht umsetzen kann und sich sonst noch keiner gefunden hat, ist die Zeit einfach organisatorisch zu kurz.


    Zitat von Feuerdrache

    dass die API vielleicht doch dauerhaft zur Verfügung gestellt wird und ihren experimentellen Charakter ablegt.

    Die WindowListener-API wird (solange es sie gibt) immer experimentell bleiben, weil Sie Dinge (Rechte / Zugriff) ermöglicht, die so eigentlich nicht mehr sein sollen. Ich könnte eine eigene (zunächst) experimentelle API für meine Zwecke erstellen und darauf hoffen, dass sie irgendwann fest für die MailExtensions eingebaut wird. Damit bin ich aber letztlich auch überfordert, woran sich auch nichts ändern wird.

    Ihr müsste Euch weiterhin bewusst machen, dass mein Add-on manuell kurzzeitig einzelne Prefs des Thunderbird manipuliert, um bestimmte Inhalte in den Mails darstellen zu lassen. Dabei wird auch nicht nur einfach pauschal zwischen "Original HTML", "Vereinfachtem HTML" und "Reintext" hin und her geschaltet. Es wird beispielsweise bei entsprechendem Tastendruck die Pref für die externen Inhalte separat manipuliert und (je nach Einstellung) ein paar Codezeilen später wieder zurück gestellt. Ich wette darauf, dass eine offizielle API überhaupt nur das umschalten der Modi ermöglichen würde, aber nicht das manipulierte Umstellen von (nur) Teilen der Modi. Daher bleibe ich auch dabei, dass mein Add-on auf Dauer sterben wird. Die einzige Chance ist die Erkenntnis, dass die Funktion einen Nutzen hat und dann von Jemandem eine saubere Integration in den Thunderbird-Code erfolgt.

    Für den 91er scheint es aber halt erstmal noch mit meinem Add-on weiter zu gehen.

    Hallo Thunder,

    Zitat von Thunder

    Falls die Einstellungen des Add-ons gesucht werden, findet man diese ab den aktuellen Beta-Versionen (und somit auch im Thunderbird 91) hier:

    leider wird diese Einstellung mit der Version 7.0a1 im aktuellem Nightly (90.0a1) nicht angezeigt.
    In der Beta 89 ist sie vorhanden. Das selbe habe ich heute mit dem PrintingTools NG 2.0.5 festgestellt.


    Gruß
    EDV-Oldi

    Zitat von jobisoft

    Starte mal TB neu, meist hat das geholfen. Ich konnte es danach aber nicht mehr reproduzieren und weiß daher nichtr was der Fehler ist.

    Leider nein, das hatte ich natürlich auch sofort gemacht,.
    Ich sehe gerade das auch QuickFolders & QuickFilters nach dem Update die Einstellung nicht mehr anzeigt.


    Gruß
    EDV-Oldi

    Zitat von jobisoft

    Starte mal TB neu, meist hat das geholfen. Ich konnte es danach aber nicht mehr reproduzieren und weiß daher nichtr was der Fehler ist.

    Ich kenne das Verhalten eigentlich nur, wenn das Add-on mittels der Funktion des Add-ons-Debugging geladen wird. Dann verschwindet das Werkzeug-Icon, bis man über das Debugging nochmals neu laden lässt.

    jobisoft

    Ich gehe davon aus, dass Deine Review-Anmerkung auf ATN nur zu meiner Information war, bevor Du 6.3.2 freigeschaltet hast? Mir ist und war klar, dass die Optionen umziehen und vereinheitlicht werden sollten.

    Zitat von Thunder

    Ich gehe davon aus, dass Deine Review-Anmerkung auf ATN nur zu meiner Information war, bevor Du 6.3.2 freigeschaltet hast? Mir ist und war klar, dass die Optionen umziehen und vereinheitlicht werden sollten.

    Ja, ich wollte nur verdeutlichen, dass ich es vorher falsch gemacht habe, was jetzt für Verwirrung sorgt. Da muss ich wohl durch.

    Uppps.... Nein, jetzt habe ich das fehlende Icon auch (nicht mehr) bei normaler XPI-Installation des Add-ons unabhängig vom Add-on-Debugging. Der Fehler besteht sowohl in 89 Beta 1 als auch im aktuellen Daily. Vermutlich ein Problem der WL-API? Das Icon fehlt, sobald man den Add-on-Manager geschlossen und wieder geöffnet hat.

    Zitat von Thunder

    Das Icon fehlt, sobald man den Add-on-Manager geschlossen und wieder geöffnet hat.

    Das kann ich bestätigen, auch mit einem neuen Profil wird es nicht angezeigt.


    Gruß
    EDV-Oldi

    jobisoft

    Das Werkzeug-Icon des Buttons für die Einstellungen wird im Dark-Mode leider schwarz auf dunklem Grund dargestellt. Es müsste aber wohl weiß auf dunklem Grund werden. Dies passiert nur bei den WL-API Add-ons, aber nicht bei den echten MailExtensions.

    Zitat von Thunder

    jobisoft

    Das Werkzeug-Icon des Buttons für die Einstellungen wird im Dark-Mode leider schwarz auf dunklem Grund dargestellt. Es müsste aber wohl weiß auf dunklem Grund werden. Dies passiert nur bei den WL-API Add-ons, aber nicht bei den echten MailExtensions.

    In den Entwicklerwerkzeugen sehe ich folgendes:

    Dein per WL-API eingefügter Button hat die Klasse extension-options-button2. Das ist ja wohl korrekt. Aber: Es fehlt dann letztlich das CSS mit den ganzen CSS-Regeln für .extension-options-button2. Statt dessen sind (fast alle Regeln direkt am Element. Dort fehlt dann aber komischer Weise folgende Zeile: -moz-context-properties: fill;.

    Ist es wirklich notwendig, dass die Klasse mit der 2 von der eigentlich originalen CSS-Klasse unterschieden wird? Wenn ich im Code der API die 2 entferne, scheint es im Daily ganz normal zu funktionieren. Dann wird das originale CSS von Thunderbird für den Button verwendet und es kann auf die ganzen Zeilen für das Hinzufügen des CSS an das Element in der API verzichtet werden. Es scheint mir, dass die eine Zeile Probleme beim Hinzufügen per JS macht.