OT-Beiträge aus dem Thread "Verfassenfenster und Empfängerzeile(n): Zunächst nur eine zeigen, bei weiteren Empfängern weitere zeigen"

  • Edit: Die folgenden Beiträge stammen aus dem Thread Verfassenfenster und Empfängerzeile(n): Zunächst nur eine zeigen, bei weiteren Empfängern weitere zeigen. graba, Gl.-Mod.




    Mapenzi

    Du hast mich missverstanden.

    Ich meinte natürlich nicht Deinen Code.


    Darüber habe ich mich gefreut. Ich achte es sehr, wenn jemand nach einer Lösung sucht und so hilfsbereit ist, Vorschläge zu posten.


    Zu der Idee mit Verbesserungsvorschlägen an Mozilla:
    Das habe ich schon vor vielen Jahren aufgegeben. Vorschläge werden nicht gehört und geschweige denn umgesetzt.


    Es fehlt aus meiner bescheidenen Einschätzung nach bei FOSS fundamental an einer etablierten Kultur, wo Nutzer z.B. durch finanzielle Anerkennung sowohl ihre Wertschätzung ausdrücken als auch gezielt Einfluss nehmen könnten. Es gibt auch keine Moderation zwischen Entwicklern und Nutzern, damit diese in einen echten wertschätzenden Austausch kommen. Das sind getrennte Welten.

    So ist man es als Nutzer gewohnt, dass FOSS oft in der Usability miserabel ist und sich das auch über viele Jahre nie ändert.
    Die typischen Aktiven bei FOSS sind eben Programmierer, die weder mit Usability und Gestaltung etwas am Hut haben. Es interessiert sie einfach nicht.


    Feuerdrache

    Ich beherrsche HTML ziemlich gut, das stimmt.


    Aber der Code von Mozilla zeigt, dass dort ganz andere Ziele verfolgt werden als prägnantes, modernes und minimalistisches HTML.

    Wenn Mozilla seine Ziele zum Code ändern würde, dann wäre ich als Berater gerne dabei, wenn der Code neu gebaut würde.

  • Hallo Andreas Borutta,


    vielleicht verstehe ich das jetzt miss:

    Ich beherrsche HTML ziemlich gut, das stimmt.


    Aber der Code von Mozilla zeigt, dass dort ganz andere Ziele verfolgt werden als prägnantes, modernes und minimalistisches HTML.

    Wenn Mozilla seine Ziele zum Code ändern würde, dann wäre ich als Berater gerne dabei, wenn der Code neu gebaut würde.


    Wenn ich mir die Basisdaten von hier ansehe, dann wird der Donnervogel mit C++ programmiert:



    Vielleicht erläuterst Du mir noch etwas genauer, was Du damit meinst. Vielen Dank im Voraus.


    Meines Erachtens wäre es vielleicht doch einen Versuch Deinerseits wert, mit den Programmentwickler mal einen (wenigstens informellen) Kontakt aufzunehmen. Wenn das Ergebnis dann ist, dass es nicht passt, dann ist eben so.


    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

  • Ich bin kein Programmierer, daher kann ich zum Entstehen des HTML aus welchem die GUI des Thunderbird besteht nichts sagen.


    Klar ist nur: die Qualität des HTML ist miserabel. Langatmig, voll mit Redundanzen, mit hässlichen Klassennamen. Eben nichts, wo man ausruft: "Schön und klar!"

  • Klar ist nur: die Qualität des HTML ist miserabel.

    Ist mir völlig egal.

    So lange Thunderbird mich bei jedem Start mit dieser Seite begrüßt, verzeihe ich ihm auch die kleinen Ungereimtheiten seiner GUI, die ich nicht selber "umbasteln" kann. Apple "Mail" zum Beispiel ist potthässlich und lässt mir keine dieser Freiheiten.



  • Die Qualität des Codes spielt eine sehr große Rolle für die Wartbarkeit durch die Entwickler/Gestalter. Je kuddelmuddeliger, desto schwerer.
    Und desto unwahrscheinlicher ist es somit bei den winzigen Ressourcen, die für Thunderbird bereit stehen, dass TB engagiert gewartet wird.

    Daher ist es mir nicht egal.

    Dass die HTML-Qualität auch die ambitionierten "Customizer" betrifft ist da ein Nebenaspekt.


    Applemail habe ich mir noch nie näher angeschaut. Ich stehe ja auf Thunderbird :) Und wie Du liebe ich die Freiheit, dass ich dort in das Erscheinungsbild der GUI eingreifen kann.

  • Interessehalber: Welcher HTML-Code ist hier eigentlich gemeint? Gibt es HTML-Code im Thunderbird? Ich dachte, der eigentliche Code des Thunderbird sei in C++ geschrieben und die GUI in XUL?

  • Damit hast du aber eher Verwirrung gestiftet. Man spricht nicht von einem Auto wenn eigentlich ein Fahrrad meint.


    Ich habe mir den XUL-Code nicht angeschaut, glaube aber nicht, dass er so schlecht oder hässlich ist, wie du behauptest. Ich bin mir nicht einmal sicher, ob du überhaupt den XUL-Code meinst oder das zugehörige CSS.

  • Nein, ich meinte das XUL, nicht das CSS.


    Da der DOMi nicht mehr nutzbar ist, kann ich gerade zumindest nicht fix ein Beispiel posten.


    Falls jemand aus dem Ärmel schüttelt, wie man das XUL eines spezifischen GUI-Bereiches ermittelt, freue ich mich über einen Hinweis.

  • [Etwas OT, wenn sich das zieht, sollte man diese Diskussion wenn in einem separaten Thread fortführen]

    Zu der Idee mit Verbesserungsvorschlägen an Mozilla:
    Das habe ich schon vor vielen Jahren aufgegeben. Vorschläge werden nicht gehört und geschweige denn umgesetzt.

    Thunderbird ist nicht Mozilla. Ich hatte bei Thunderbird da noch nie Probleme. Wenn mich in der Vergangenheit etwas konkretes gestört hat, wurden Patches über die Bugzilla eigentlich immer dankend angenommen. Natürlich ggf. erst nach ein paar kleinen Revisionen.


    Vorschläge ohne Patches werden dort ebenfalls gesammelt, sodass diese zumindest von externen Entwicklern implementiert werden könnten – oder in eindeutigen Fällen begründet abgelehnt. Voraussetzung für beides ist aber natürlich, dass man saubere Einträge schreibt. Bugzilla ist keine allgemeine Diskussionsplattform für unausgereifte Ideen, auch wenn sie gelegentlich dafür missbraucht wird ;)


    Wenn man also etwas an der Codequalität in XUL ändern will reicht es nicht, das im Allgemeinen zu kritisieren. Es wäre dann auch nötig, konstruktive Vorschläge zu haben wie die Qualität konkret erhöht werden soll und idealerweise direkt Patches zu liefern.


    (In dem konkreten Fall bin ich aber etwas befangen: alles was ich bisher zu dem Thema UI-Refactoring für Thunderbird gesehen habe waren eher Verschlimmbesserungen; das Problem ist komplexer als es beim ersten Durchlesen erscheint, insbesondere da die Strukturen nicht nur von Thunderbird sondern auch von Add-ons genutzt werden. So extrem schlecht ist der Status quo gar nicht, nach unten ist da noch viel Luft...)


    Es fehlt aus meiner bescheidenen Einschätzung nach bei FOSS fundamental an einer etablierten Kultur, wo Nutzer z.B. durch finanzielle Anerkennung sowohl ihre Wertschätzung ausdrücken als auch gezielt Einfluss nehmen könnten.

    Es gibt einen Weg der eigentlich immer funktionieren sollte: beauftrage jemanden für Dich Patches zu schreiben und für dich einzureichen. Du solltest nur vorher nachfragen, ob eine konkrete Funktion / Änderung prinzipiell aufgenommen werden würde. Das ist ja gerade der Vorteil von einem offenen Projekt: jeder kann Code einreichen / beauftragen. Auf diese Weise spürt man auch gleich, welcher Aufwand für einen Funktionswunsch tatsächlich anfällt und kann so manche Entscheidung der Kern-Entwickler vielleicht besser nachvollziehen.


    Ansonsten kannst Du auch direkt an das Projekt spenden und diesem vertrauen, deine Mittel sinnvoll einzusetzen. So verbraucht Thunderbird derzeit meines Wissens einen Großteil ihrer Ressourcen darauf, die aus Firefox-Änderungen resultierenden Probleme zu fixen. Das ist aus meiner Sicht eine eine sinnvolle Verwendung, wenn auch schwer vermittelbar. Darüber hinaus gibt es inzwischen eine Person, die sich (iirc als halbe Stelle) ganz darauf konzentriert, Öffentlichkeitsarbeit zu machen und so zumindest in bescheidenen Rahmen deinen Kultur-Wunsch zu erfüllen. Einfluss haben Nutzer hier aber natürlich nur als Masse, z.B. in den Umfragen. Alles andere wäre finanziell schlicht nicht machbar.

    Falls jemand aus dem Ärmel schüttelt, wie man das XUL eines spezifischen GUI-Bereiches ermittelt, freue ich mich über einen Hinweis.

    In Thunderbird 60 funktionieren die bordeigenen Tools von Firefox, ein Add-on ist nicht mehr nötig: Extras|Entwickler-Werkzeuge|Entwickler-Werkzeugkasten im Menü öffnen, die Meldung bestätigen und in den Tab "Inspektor" wechseln. Mit dem Frame-Dropdown oben rechts (Rechteck mit rechtwinkligen Linien darin) kann das Fenster ausgewählt werden.

  • generalsync

    Danke für Deine ausführliche Antwort.
    Du sprichst vom Umgang von Thunderbird mit vorgeschlagenen Patches, also von Beiträgen von Programmierern.


    Ich sprach dagegen von Beiträgen von Nicht-Programmierern.

    Fallen Dir Beispiele aus der jüngeren Vergangenheit ein, wo Vorschläge von Nicht-Programmierern (also ohne Patches) von Thunderbird umgesetzt wurden?


    Zu Deinem Vorschlag, dass man selber jemanden gegen Entgelt beauftragen kann, Patches zu schreiben. Klar, sowas ginge. Aber wer will schon ganz allein für solche Summen aufkommen. Ich dachte an einen strukturierten Prozess, an dem sich beliebig viele Nutzer finanziell beteiligen können. Dem Crowdfoundingkonzept sehr ähnlich.


    Das scheint bei TB und vielen anderen FOSS-Projekten nicht zu existieren und ist eben hinzunehmen.


    Zum Ersatz des DOMi:

    Danke für Deinen Hinweis.


    Mir gelingt zwar das Auswählen des Verfassenfensters und sogar das Finden eines UI-Bereiches (z.B. das Feld "An") per Schaltfläche "Ein Element der Seite auswählen" (Symbol oben links).

    Aber der dazugehörige Code wird nach einem Klick auf den UI-Bereich nicht markiert, so dass man ihn in dem Gesamtcode findet.

    Ich hoffe, es ist verständlich, was ich meine. Wenn nicht, versuche ich, es noch besser zu beschreiben oder einen Screencast zu posten.

  • Mir gelingt zwar das Auswählen des Verfassenfensters und sogar das Finden eines UI-Bereiches (z.B. das Feld "An") per Schaltfläche "Ein Element der Seite auswählen" (Symbol oben links).

    Vielleicht so?

    Identifizieren des Elements (ID) der GUI (hier "addressingWidget"), dann in der rechten Spalte "Regeln" die entsprechende css-Datei im Thunderbird Code suchen:



    Danach in das Tab "Stilbearbeitung" wechseln und in der linken Spalte "messengercompose.css" öffnen und zur Zeile 254 gehen. Darunter befinden sich sämtliche Regeln zu #addressingWidget



  • Fallen Dir Beispiele aus der jüngeren Vergangenheit ein, wo Vorschläge von Nicht-Programmierern (also ohne Patches) von Thunderbird umgesetzt wurden?

    Mir fallen überhaupt nur sehr wenige neue Funktionen ein, die durch das Kern-Team hinzugefügt wurden. Das Team ist klein und der Aufwand für die Fehlerbehebung und ständige Wartung sehr hoch – viel Zeit bleibt da nicht. Dafür müsste es deutlich mehr Spenden geben. Ich glaube, Teile der neuen Oberfläche für Kontakt-Bilder gingen auf Vorschläge von Dritten zurück, bin mir da aber gerade nicht sicher.

    Wenn man "von Thunderbird" weiter fasst: es gibt auch externe Entwickler, die Vorschläge von anderen umgesetzt haben, z.B. kommt für Thunderbird 66 wohl die Option, Favoriten für die Verschiebe- und Kopier-Aktionen anzulegen. Vorgeschlagen wurde die Funktion vor 9 Jahren, vor 8 Tagen wurde sie offiziell in den Entwicklungszweig aufgenommen.


    Ich dachte an einen strukturierten Prozess, an dem sich beliebig viele Nutzer finanziell beteiligen können. Dem Crowdfoundingkonzept sehr ähnlich.

    Solche Ansätze gibt es, in allen mir bekannten Fällen kommen so aber selbst für extrem populäre Funktionen maximal einige hundert Euro zusammen. Bei "normalen" Funktionen sogar noch mal deutlich weniger. Überweisungsgebühren, Steuern und anderen Abgaben reduzieren den effektiven Betrag dann nochmals. Mehr als ein Anreiz sind solche Aktionen also i.d.R. nicht – auf Stunden gerechnet kommt nicht einmal Mindestlohn zusammen. Abgesehen von der Crowdfunding-Plattform verdient wohl keiner daran.


    Aber der dazugehörige Code wird nach einem Klick auf den UI-Bereich nicht markiert, so dass man ihn in dem Gesamtcode findet.

    Ich bin mir nicht sicher, was du meinst. Die Entwicklerwerkzeuge zeigen natürlich nur das DOM (= Struktur des Fensters, so wie es gerade angezeigt wird) und nicht den eigentlichen Thunderbird-Quelltext (= Code, aus dem das DOM erzeugt wird). Letzteren solltest Du aber nicht brauchen, wenn Du kein Entwickler bist (wenn doch: suche nach Identifiern und verwende Sie als Suchanfrage in dxr für comm-central und dxr für mozilla-central; Links sind jeweils für TB 60).


    Wenn du das CSS für die grafische Darstellung der Elemente meinst, hat Mapenzi oben eine Anleitung gepostet.

  • Mir fallen überhaupt nur sehr wenige neue Funktionen ein, die durch das Kern-Team hinzugefügt wurden. Das Team ist klein und der Aufwand für die Fehlerbehebung und ständige Wartung sehr hoch – viel Zeit bleibt da nicht. Dafür müsste es deutlich mehr Spenden geben. Ich glaube, Teile der neuen Oberfläche für Kontakt-Bilder gingen auf Vorschläge von Dritten zurück, bin mir da aber gerade nicht sicher.

    Wenn man "von Thunderbird" weiter fasst: es gibt auch externe Entwickler, die Vorschläge von anderen umgesetzt haben, z.B. kommt für Thunderbird 66 wohl die Option, Favoriten für die Verschiebe- und Kopier-Aktionen anzulegen. Vorgeschlagen wurde die Funktion vor 9 Jahren, vor 8 Tagen wurde sie offiziell in den Entwicklungszweig aufgenommen.

    Das bestätigt ja letztlich meine Einschätzung, dass es sich nicht lohnt Vorschläge zu machen.



    Solche Ansätze gibt es, in allen mir bekannten Fällen kommen so aber selbst für extrem populäre Funktionen maximal einige hundert Euro zusammen. Bei "normalen" Funktionen sogar noch mal deutlich weniger. Überweisungsgebühren, Steuern und anderen Abgaben reduzieren den effektiven Betrag dann nochmals. Mehr als ein Anreiz sind solche Aktionen also i.d.R. nicht – auf Stunden gerechnet kommt nicht einmal Mindestlohn zusammen. Abgesehen von der Crowdfunding-Plattform verdient wohl keiner daran.

    Danke auch hier für Deinen Einblick.

    Vielleicht ist dann also FOSS doch ein fehlgeschlagener Ansatz, wenn Nutzer sich Software wünschen, die aktiv und stetig weiterentwickelt wird und wo ein hoher Anspruch an die Usability gestellt wird und wenn sich Entwickler gleichzeitig wünschen von ihrer Arbeit leben zu können.

    Ich kenne die Geschichte der Kultur von FOSS nicht ausreichend um dazu fundiert diskutieren zu können.

    Identifizieren des Elements (ID) der GUI (hier "addressingWidget"), dann in der rechten Spalte "Regeln" die entsprechende css-Datei im Thunderbird Code suchen: [Screenshot]

    Bei Dir wird im linken Teil Deines ersten Screenshots der Code blau hinterlegt - dort kann man den passenden Selektor für eigene CSS-Regeln ermitteln. Das Hinterlegen in blau gelingt mir nicht. Vielleicht liegt es am OS?

  • Bei Dir wird im linken Teil Deines ersten Screenshots der Code blau hinterlegt - dort kann man den passenden Selektor für eigene CSS-Regeln ermitteln. Das Hinterlegen in blau gelingt mir nicht.

    Ich beschreibe hier nochmal meine Vorgehensweise:

    • Verfassen-Fenster öffnen

    • Im Hauptfenster-Menü Extras > Entwickler-Werkzeuge > Entwickler-Werkzeugkasten

    • Verfassen-Fenster und Entwicklerwerkzeuge-Fenster nebeneinander setzen

    • in Entwicklerwerkzeuge über den Iframe-Button das Zieldokument chrome://messenger/content/messengercompose/messengercompose.xul markieren

    • den Auswahl-Button in der linken oberen Ecke aktivieren

    • ins Verfassen-Fenster wechseln, mit der Maus den GUI-Bereich überfliegen, den man erkunden möchte. Wenn der flottierende rote Rahmen den entsprechenden Bereich umfasst, mit der Maus darauf klicken

    • in den Werkzeugkasten wechseln, in dem inzwischen die Code-Hierarchie (der Code-Baum) aufgeklappt worden ist

    • mit der Maus den Code-Baum nach oben und/oder nach unten überfliegen und dabei den roten Rahmen im Verfassen-Fenster beobachten.

    • Wenn der rote Rahmen die Adresszeilen umfasst, wird das entsprechende Element im Code-Baum leicht bläulich hinterlegt:



    • Wenn man jetzt auf die bläulich markierten Zeilen im Code-Baum klickt, werden sie mit einem fixen dunkelblauen Hintergrund markiert.


    Ich gebe zu, dass diese Methode im Vergleich zu dem alten DOM Inspector recht umständlich ist, aber ich habe noch keinen kürzeren oder schnelleren Weg gefunden. Wahrscheinlich gibt es im Forum Experten, die eine bessere Methode kennen.

  • Du hast also den Code mühsam gesucht

    "Code" ist in dieser Etappe nicht das richtige Wort, aber ich vermute du meinst den #Namen bzw die ID des Elements.

    Das Finden der iD ist nach meinen bisherigen Versuchen jetzt schwieriger als mit dem alten DOMI.


    Die nächste Etappe unter dem Reiter "Stilbearbeitung" - das Anzeigen der für dieses Element (hier #addressingWidget) benutzten CSS-Code - ist dann vergleichsweise relativ einfach.

    Aber selbst das fand ich einfacher mit dem alten DOMi über den Rechtsklick > Datei ansehen:



  • Ein hoffentlich letzter OT-Beitrag:

    Vielleicht ist dann also FOSS doch ein fehlgeschlagener Ansatz, wenn Nutzer sich Software wünschen, die aktiv und stetig weiterentwickelt wird und wo ein hoher Anspruch an die Usability gestellt wird und wenn sich Entwickler gleichzeitig wünschen von ihrer Arbeit leben zu können.

    FOSS hat nur wie jeder andere Ansatz auch Grenzen des Machbaren. Aktive und stetige Weiterentwicklung ist möglich, gute Usability schwieriger aber bei entsprechender Projektgröße und Ressourcen (Spenden, Sponsorings in Geld oder Entwickler-Zeit) durchaus machbar. Blender ist da ein gutes Beispiel, wie es zumindest in manchen Domänen funktionieren kann. Dort dürfen die Unterstützer auch über die grobe Entwicklungsrichtung abstimmen. Was aber nicht geht, ist dass sich Nutzer ohne "großen" Beitrag (in Zeit und/oder Geld) individuell Funktionen wünschen können. Es wird immer viel mehr Wünsche geben, als erfüllt werden können – das ist aber auch außerhalb von FOSS der Fall. Dort ist aber komischerweise keine so große Erwartungshaltung seitens der Nutzer vorhanden.


    Ich persönlich halte FOSS großartig für Projekte mit großer Unterstützerbasis (z.B. durch Firmen oder viele regelmäßige Kleinspender) und kleine "Hobbyprojekte". Dazwischen war das Konzept bislang nur selten erfolgreich, daher entwickle ich auch GeneralSync derzeit auch nicht unter einer offenen Lizenz. Aber das macht FOSS noch lange nicht zu einem Fehlschlag.