Gut erkannt...
Stimmt bitte per "Vote" auf BugZilla für die Integration direkt in Thunderbird
-
Thunder -
23. November 2019 um 13:22 -
Geschlossen -
Unerledigt
-
-
Eröffne einen neuen Beitrag im Bereich Erweiterungen und stelle dort die Frage nach einer Alternative zur genannten Erweiterungen und/oder auch nach anderen....
Ggf. guckst hier mal rein...
Hab ich mal gemacht! Danke!
-
Frage, bringt das Votieren (auch ein deutsches Wort für das denglische voten) überhaupt was? Ich meine ich habe mal von Sören Hentzschel gelesen, dass sich das keiner der Entscheider anschauen würde.
Wäre es daher vielleicht zielführender, diesen Wunsch auf anderem Wege einzukippen, vielleicht über eine der Google-Gruppen oder so?
-
Wäre es daher vielleicht zielführender, diesen Wunsch auf anderem Wege einzukippen, vielleicht über eine der Google-Gruppen oder so?
Gute Frage
-
Ich habe jetzt mal noch einen weiteren RFE Bug erstellt, der das Überleben des Add-ons ermöglichen würde:
-
Da ist aber keine Vote-Möglichkeit?!
-
Da ist aber keine Vote-Möglichkeit?!
Doch! Du musst dich dort zuerst einloggen.
-
-
Und du hast unter "Details" nachgeschaut?
-
Jetzt ja... ich werde es mir irgendwohin schreiben, das man DORT nachsehen muß..
Vielen Dank!
-
Nur bitte unterlasst im Allgemeinen den "Erpressungs-Tonfall" in den Bugs, wobei mir das durchaus auch schwer fällt
-
Ohne Kommentar votiert
16 Stimmen beim Ersten, 5 beim Zweiten, ist ein wenig dünne.
Was mich stört, unter "show votes" finden sich unsere Mailadressen im Klartext. Der user würde reichen!
-
ist ein wenig dünne.
Das ist doch nicht verwunderlich. Die meisten Benutzer benutzen den Thunderbird nur. Die tummeln sich ganz gewiss nicht auf bugzilla und suchen dort nach RFEs, die sie betreffen könnten. Sie wissen wahrscheinlich nicht einmal, dass es technische Änderungen geben wird, die ein Aus für diese Erweiterung sein sein könnten.
Ich würde es eher an der Benutzer- oder Download-Zahl der Erweiterung festmachen. Deshalb noch mal die Frage nach anderen Wegen. Es gibt doch hier Leute mit Verbindungen in den engeren Kreis der Erlauchten. Da sollte es doch möglich sein, zumindest mal die Aufmerksamkeit zu bekommen.
-
Das ist doch nicht verwunderlich. Die meisten Benutzer benutzen den Thunderbird nur. Die tummeln sich ganz gewiss nicht auf bugzilla und suchen dort nach RFEs, die sie betreffen könnten. Sie wissen wahrscheinlich nicht einmal, dass es technische Änderungen geben wird, die ein Aus für diese Erweiterung sein sein könnten.
Dem kann ich nur zustimmen. Ich kenne viele Leute, welche Produkte oder unterstützte Projekte von Mozilla verwenden, aber von Bugzilla haben die noch nie gehört!
-
Hallo Leute!
Ich habe jetzt mal noch einen weiteren RFE Bug erstellt, der das Überleben des Add-ons ermöglichen würde:
Ich habe die letzten Tage nun selbst an einer experimentellen API gearbeitet, die als Grundlage für eine in Thunderbird integrierte API dient. Die API findet sich hier:
api/messageContentPolicy · main · ThunderbirdMailDE / messageContentPolicy API · GitLabThis is an experimental Thunderbird MailExtension API to implement a HTML mode toggle, which can be used by MailExtensions. A function to reload the displayed…gitlab.comWie man die API verwendet, ist anhand des beispielhaften Add-ons zu sehen (siehe manifest.json und background.js):
ThunderbirdMailDE / messageContentPolicy API · GitLabThis is an experimental Thunderbird MailExtension API to implement a HTML mode toggle, which can be used by MailExtensions. A function to reload the displayed…gitlab.comUnd das ganze habe ich beim Erstellen der API dann gleich auch in Allow HTML Temp integriert: allow-html-temp_20220525-232659.xpi
Diese Version basiert auf AHT 8.0.2 (gerade aktuell auf ATN) und ersetzt im Code die LegacyPrefs-API von jobisoft. Die LegacyPrefs-API wird in dieser Version nur noch für die Migration von alten Prefs in das neue System verwendet, was letztlich ein einmaliger Schritt ist, wenn man von Versionen bis inkl. 7.* auf eine 8er-Version aktualisiert.
Ich würde mich freuen, wenn Ihr mit der hier bereitgestellten Version bei Euch arbeiten würdet, sodass ich bei eventuellen Problemen eine Rückmeldung von Euch bekommen kann, bevor ich das Ganze auf alle Anwender "los lasse". Ach ja, es sind noch ein paar Log-Zeilen drin, die später dann noch entfernt werden - das schadet ja aber erstmal nicht in der Konsole
-
Ich würde mich freuen, wenn Ihr mit der hier bereitgestellten Version bei Euch arbeiten würdet, sodass ich bei eventuellen Problemen eine Rückmeldung von Euch bekommen kann
Habe die neue Version im Daily installiert und sehe im Moment keine Probleme, Installation OK, Anzeige der Daten (Details, Einstellungen, Rechte) auch OK. Schaltfläche ist da.
-
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?
-
Für Thunderbird 102 schaffe ich es nicht mehr
Das war auch gar kein Anspruch Aktuell steht erstmal alles für das Release im Vordergrund.
Hab ich was übersehen?
Ein "Traum" wäre es, wenn das erlauben einer bestimmten Einstellung persistent für den jeweiligen Tab wäre. Dann würde beispielsweise vielleicht auch das Drucken mit dieser gewählten Einstellung funktionieren. Momentan "verliert" der Tab ja beim Wechsel zwischen den Tabs die Einstellung, weil die message immer wieder neu geladen wird und dann ja die zurückgestellte Einstellung wieder verwendet wird. Dieser "Verlust" trat früher (vor Thunderbird 91) auch beim Drucken auf. Seit 91 funktioniert das Drucken auch korrekt, solange man nicht die Printing Tools NG verwendet. Der Verlust tritt aber natürlich auch bei jedem Antworten und Weiterleiten auf. Eine Tab-bezogene persistente Möglichkeit wäre also sehr gut.
Übersehen hast Du aber womöglich dennoch etwas, was ich vorhin schon auf BugZilla geschrieben habe. Die API soll ja auch für Addons sichtbar machen, wie die relevanten globalen Prefs eingestellt und (durch das Thunderbird UI) verändert werden. Nur dann könnte bspw. Dillingers Add-on "Toggle HTML" seinen Button live aktualisieren. Dillingers Button ist in diesem Punkt nämlich unzureichend programmiert. 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.
-
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.
-
Niemand braucht Zugriff auf die globalen Einstellungen,
Dann ist es aber auch tatsächlich nicht mehr möglich, um gut gemeinte Add-ons für den leichteren Zugriff auf Einstellungen anzubieten - jedenfalls, wenn die Experimente irgendwann unmöglich würden. In der Hinsicht finde ich meinen Ansatz mit der API halt durchaus einen Kompromiss - zumal man noch diskutieren könnte auf manche Dinge nur einen lesenden Zugriff anzubieten. Aber dies will man ja auch aus Prinzip für die Prefs nicht, was ich hier gar nicht länger diskutieren will
-