Verfassenfenster und Empfängerzeile(n): Zunächst nur eine zeigen, bei weiteren Empfängern weitere zeigen

  • Per Default werden im Verfassenfenster 3 leere Empfängerzeilen gezeigt.


    Gibt es einen Weg, vielleicht über eine Erweiterung oder CSS, die Darstellung so zu verändern, dass beim Aufrufen des Verfassenfensters nur eine Zeile angezeigt wird und - das ist wesentlich - erst dann eine weitere, wenn man per ENTER einen weiteren Empfänger hinzufügen möchte.


    Der Eintrag "mail.compose.addresswidget.numRowsShownDefault" in about:config ist nicht verwendbar.


    Denn wenn man ihn auf 1 setzt, wird erstens bei der Eingabe eines weiteren Empfängers keine weitere Zeile eingefügt und zweitens ist auch kein Scrollbalken dauerhaft sichtbar, der deutlich signalisiert "da ist noch was".

    Fällt euch zu der Sache eine Lösung ein?

    Danke.

  • Hallo Andreas,

    Fällt euch zu der Sache eine Lösung ein?

    Ich habe mir das überlegt, wobei ich davon ausging, dass du eine minimalistische GUI erreichen willst.

    Wenn ich den Wert der Einstellung "mail.compose.addresswidget.numRowsShownDefault" auf 1 stelle, wird die geringste Höhe des Kastens mit den Adress- und Betreff-Zeilen erreicht. Wie du schon bemerkt hast, wird dann aber die Ansicht bei Eingabe von mehreren Empfängern in jeweils einer neuen Zeile unübersichtlich, da kein Scrollbalken angezeigt wird.

    Deshalb habe ich einen Code für die Minimal- und Maximalhöhen (genauer gesagt eine fixe Höhe) dieses Kastens getestet und heraus gefunden, dass bei Verwendung des folgenden CSS-Codes


    #addressingWidget {

    min-height: 35px !important;

    max-height: 35px !important; }


    tatsächlich der Scrollbalken ab der zweiten Adresszeile angezeigt wird trotz Beibehaltung der Einstellung "mail.compose.addresswidget.numRowsShownDefault" = 1


    Der folgende Screenshot zeigt ein neues Verfassen-Fenster bei Verwendung des obigen Codes:



    Die Höhe des Kasten liegt also nur geringfügig über der Standardhöhe bei Verwendung von mail.compose.addresswidget.numRowsShownDefault = 1 .


    Nach Eingabe der ersten Adresse springt der Cursor automatisch in die nächste (neu angezeigte) Adresszeile und rechts wird nun der Scrollbalken angezeigt :



    Da du offenbar ebenfalls macOS benutzt, sollte der Code auch bei dir funktionieren. Du kannst gegebenenfalls die Pixelzahl leicht erhöhen, damit die erste Adresszeile nicht etwas abgeschnitten wirkt wie in meinem Screenshot.


    Natürlich kann man auch den Kasten auch manuell leicht vergrößern, indem man mit dem Mauszeiger den Trennbalken etwas nach unten zieht. Auch dann erscheint der Scrollbalken ab der zweiten Adresszeile, leider wird diese Einstellung aber nicht gespeichert für die nächste Session.

    Edited once, last by Mapenzi: Tippfehler im Code korrigiert (statt maw => max) ().

  • Erstmal herzlichen Dank für Deine Mühe :)

    Ich habe den Code gestestet. Leider bleibt (hier auf macOS) der Scrollbalken flüchtig.

    https://www.dropbox.com/s/slkc…2019-01-06%2008.36.53.png


    Der Scrollbalken ist nur zu sehen, wenn man das Scrollrad bewegt, während sich der Cursor in einer der Empfängerzeilen befindet.


    Unabhängig davon:

    Empfindet ihr die aktuelle Gestaltung von Empfängerzeilen und Betreffzeile schön?


    Ich empfinde es als sehr ungewöhnlich und daher irritierend, dass z.B. ein noch leeres Betrefffeld nicht aussieht wie ein Eingabefeld (sieht man im Screenshot), sondern grau und ohne Rahmen daherkommt.
    Hat das jemand von euch schonmal per CSS "repariert"?


    Auch die verdickte Rahmenlinie oberhalb der ersten Empfängerzeile ist unschön.

  • Der Scrollbalken ist nur zu sehen, wenn man das Scrollrad bewegt, während sich der Cursor in einer der Empfängerzeilen befindet.

    Verstehe ich nicht. Bei mir erscheint der Scrollbalken, sobald ich die erste Adresse eingefügt habe, und bleibt sichtbar unabhängig davon , wo sich der Mauszeiger befindet :



    Übrigens hatte sich ein Tippfehler in meinen Code eingeschlichen (maw statt max), ich habe ihn inzwischen korrigiert.

    Du kannst erneut mit dem korrigierten Code testen, ich glaube aber nicht, dass in diesem Fall der falsche Buchstabe entscheidend ist. Du kannst auch weitere Tests mit etwas mehr oder weniger Pixeln machen. Übrigens sind meine Tests und Screenshots auf einem iMac 21.5" Retina unter macOS High Sierra gemacht.

    Empfindet ihr die aktuelle Gestaltung von Empfängerzeilen und Betreffzeile schön?


    Ich empfinde es als sehr ungewöhnlich und daher irritierend, dass z.B. ein noch leeres Betrefffeld nicht aussieht wie ein Eingabefeld (sieht man im Screenshot), sondern grau und ohne Rahmen daherkommt.

    Ich finde den Adresskasten auch nicht sehr sexy in der Mac-Version. Er wurde in der Vergangenheit mehrfach umgemodelt, in früheren Version waren tatsächlich alle Zeilen deutlich abgegrenzt und hatten einen weißen Hintergrund.

    Ich habe noch einen Code, mit dem man das in der Version 52 wiederherstellen konnte, aber dieser Code hat unschöne Nebeneffekte in der v60. Vielleicht findest du bei einer Suche einen ähnlichen Code, der besser an die v60 angepasst ist.


    In meinem Arbeitsprofil habe ich den oberen Kasten und die Werkzeugleiste ein bisschen eingefärbt und die Schriften vergrößert, lasse allerdings standardmäßig zwei Adresszeilen anzeigen . Für meine Bedürfnisse ist das ausreichend:



  • Dass wir beide ein unterschiedliches Verhalten beim Scrollbalken feststellen ist wirklich merkwürdig.


    Ob es was mit dem dem OS zu tun hat?


    Ich habe hier anders als Du macOS Mojave.


    der Scrollbalken ist hier in allen TB-Interfaces "flüchtig".


    Zum CSS und den weißen Formularfeldern:

    Ich bin in der Analyse des Kuddelmuddel-HTML des UI leider nicht geschickt.


    Falls also ein Leser zu TB60 ein Hack hinbekommt, freue ich mich über einen Hinweis.

  • Ich bin in der Analyse des Kuddelmuddel-HTML des UI leider nicht geschickt.

    Kannst du alles selber rauskriegen über Thunderbirds "Entwicklerwerkzeuge" und/oder mit den Add-ons "DOM Inspector Plus" und "InspectorWidget". Warum die Arbeit immer den anderen überlassen ;)

    Dass wir beide ein unterschiedliches Verhalten beim Scrollbalken feststellen ist wirklich merkwürdig.

    Vielleicht benutzt du noch andere Code, die dieses Verhalten beeinflussen könnten?

    Wenn ich ganz sicher gehen will beim Testen eines neuen Codes, dann entferne ich vorübergehend alle anderen Codes aus meiner userChrome.css Datei oder teste in einem neuen Profil, so ähnlich wie beim Bestâtigen eines Bugs.

  • Mapenzi

    Thunderbirds Entwicklerwerkzeuge kenne ich.

    Die Regeln für einige Manipulationen suche ich mir auch selber raus. Aber für das Kuddelmuddel-HTML ist es oft extrem schwer passende Selektoren zu Deklarationen zu finden.

    Und die Tippsammlung, die ich seit eineinhalb Jahrzehnten pflege macht schon reichlich Arbeit :)
    Daher freue ich mich über Hilfe von userChrome.css-Könnern.


    Zum Scrollen:

    Meine Vermutung stimmte. Es lag an Mojave. Der Default dort ist ein flüchtiger Scrollbalken.
    Das kann in den Einstellungen abgeschaltet werden.
    https://www.dropbox.com/s/sdd5…01-07%2007.34.19.png?dl=0

    So ist Deine Lösung auf jeden Fall ein verwendbarer Workaround, danke nochmal dafür :)


    Nachteil: sobald man eine zweiten Empfänger eingibt ist er "angeschnitten", also nur teilweise sichtbar. Das sieht "gebastelt" aus.

    Ich habe mich daher entschieden "mail.compose.addresswidget.numRowsShownDefault" auf "2" zu setzen, da es eine richtige Lösung, wie ich sie im Ausgangsposting erfragt habe, ja nicht gibt.

    Bleibt also die Suche nach passenden CSS-Regeln für "weiße Formularfelder mit grauer Rahmenlinie" auch bei leeren Formularfeldern.

  • Daher freue ich mich über Hilfe von userChrome.css-Könnern.

    Zu denen zähle ich mich nicht ;)

    Ich bin nur ein Sammler wie du und gelegentlich werde ich zum Handwerker, wenn mir etwas in einer neuen TB-Version nicht gefällt oder wenn hier im Forum jemand nach Änderungen der GUI fragt.


    Bleibt also die Suche nach passenden CSS-Regeln für "weiße Formularfelder mit grauer Rahmenlinie" auch bei leeren Formularfeldern.

    In meinem Screenshot von gestern wird das Verfassen-Fenster meines Arbeitsprofils von 60.4.0 gezeigt. Dort wird beim Öffnen eines neuen Verfassen-Fensters nicht nur das erste Adressfeld mit weißem Hintergrund angezeigt, sondern auch das Betreff-Feld, was standardmäßig nicht der Fall ist. Ich weiß allerdings im Augenblick nicht mehr, wie ich das zustande gebracht habe und muss erst mal alle Regeln in meiner userChrome.css Datei durchforsten.


    ---------------------

    EDIT: inzwischen habe ich den entsprechenden Code wieder gefunden:


    textbox {

    background: #F8F8FF !important; }


    Er stand in meiner userChrome.css Datei unter /* Diverse */, und das zu recht, denn er wirkt nicht nur auf diese Felder (Adressen und Betreff) im Verfassen-Fenster, sondern auch in anderen Feldern, z. B. den Suchboxen. Meine Augen empfinden das Ghost white #F8F8FF als angenehmer als das helle Weiß #FFFFFF


    -------------------------

    Ich kann dir aber trotzdem den Code geben, mit dem man noch in der Version 52 sämtliche Felder weiß anzeigen lassen kann, so wie es in den früheren Versionen der Fall war:



    Das sieht dann in meinem 52.9.1 Profil so aus:



    Vielleicht kannst du einige Bruchstücke des obigen Codes in der Version 60 testen. Ich hatte bisher noch keine Lust dazu.

    Edited once, last by Mapenzi ().

  • Eine Regel, die auf alle Textboxen wirkt ist mir erstmal zu heikel.

    Na ja, das helle Ghost white #F8F8FF in einem Testfeld ist sicher nicht so auffällig wie dunkelrot oder dunkelblau ;)


    Vielleicht liest ja noch jemand mit, dem es gelingt einen spezifischen Selektor für die Empfängerzeilen und den Betreff zu ermitteln.

    Die Selektor-ID ist doch ganz einfach heraus zu finden: siehe meinen Beitrag #6 .

    Ich hatte nicht gedacht, dass ein solcher Hintergrund in allen Textfeldern für dich so heikel ist, sonst hätte ich die ID gleich mit geliefert. Teste doch mal


    #addresses-box textbox {

    background: #F8F8FF !important; }


    Wenn du dich hâufiger mit userChrome.css beschäftigst, musst du dich mit DOM Inspector Plus und InspectorWidget und/oder dem Thunderbird Entwickler-Werkzeugkasten befreunden.

  • Mapenzi

    Meine Talente liegen woanders und nicht beim Analysieren des Kuddelmuddelcodes von TB. Wäre es schöner Code, würde ich mich darauf einlassen. Aber er ist wirklich grottenhässlich.


    Zu Deiner Regel.


    So einfach ist es leider nie. So auch diesmal.


    https://www.dropbox.com/s/064g…01-08%2012.10.40.png?dl=0


    Damit es einigermaßen akzeptabel aussieht, müssten


    * die grauen horizontalen Linien (die keine Rahmenlinien der Boxen sind) weg

    * auch Boxen, in denen die Einfügemarke gerade nicht ist, sollten Rahmenlinien haben

    * auch die Box mit dem Absender sollte aussehen wie alle anderen Boxen, also weiß und mit grauer Haarlinie


    Besser wäre es, wenn TB die Gestaltmerkmale der jeweiligen Plattform übernehmen würde. Alles andere sieht gebastelt aus.

  • Aber er ist wirklich grottenhässlich.

    Tut mir leid, dass ich mehrere Tage verplempert habe, um dir einen grotten-hässlichen Code anzudrehen. Wird nicht wieder vorkommen, schließlich bin ich kein Kundendienstler für Mozilla.

    Außerdem geht es hier nicht um einen Schönheitswettbewerb!

    Damit es einigermaßen akzeptabel aussieht, müssten

    Für Verbesserungsvorschläge oder -wünsche (feature requests, enhancements) wendest du dich am besten an Bugzilla Mozilla https://bugzilla.mozilla.org/

  • Hallo Mapenzi,


    Tut mir leid, dass ich mehrere Tage verplempert habe, um dir einen grotten-hässlichen Code anzudrehen.


    ich glaube, dass Du da einem Missverständnis aufsitzt. Er meint sicherlich nicht Deinen CSS-Code.


    Ich gehe mal davon aus, dass Andreas Borutta den Quellcode des Thunderbird-Programms selbst meint. Wenn er aber so gut ist, dass er den Programmcode so beurteilt, wie er diesen hier als 'grotten-hässlich' beurteilt hat, dann sollte er eventuell auch in der Lage sein, der Gemeinschaft der Thunderbird-Programmierer seine Hilfsbereitschaft anzubieten.

    Diese sind sicherlich für jeden zusätzlichen Helfer dankbar, der beim Verbessern der bestehenden Codebasis mitwirkt.


    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

  • Die ursprünglich hier folgenden Beiträge habe ich in einen neuen Thread OT-Beiträge aus dem Thread "Verfassenfenster und Empfängerzeile(n): Zunächst nur eine zeigen, bei weiteren Empfängern weitere zeigen" verschoben, da sie größtenteils nicht mehr zu dem eigentlichen Thema passten. Bitte ggf. dort weiterschreiben.